This technical note describes why text doesn’t always look the way you expect depending on the environment you are in.
There are a number of Macintosh text editing applications where layout is critical. Unfortunately, text on a newer machine sometimes prints differently than text on a 64K ROM Macintosh. Let’s examine some differences you should expect and why.
The differences we will consider here are only differences in the layout of text lines (line layout), not differences in the appearance of fonts or the differences between different printers. Differences in line layout may affect the position of line, paragraph and page breaks. The four variables that can affect line layout are fonts, the printer driver, the font manager mode, and ROMs.
Fonts
Every font on a Macintosh contains its own table of widths which tells QuickDraw how wide characters are on the screen. For every style point size there is a separate table which may contain widths that vary from face to face and from point size to point size. Character widths can vary between point sizes of characters even in the same face. In other words, fonts on the screen are not necessarily linearly scalable.
Non-linearity is not normally a problem since most fonts are designed to be as close to linear as possible. A font face in 6 point has very nearly the same scaled widths of the same font face in 24 point (plus or minus round-off or truncation differences). QuickDraw, however, requires only one face of any particular font to be in the System file to use it in any point size. If only a 10 point face actually exists, QuickDraw may scale that face to 9, 18, 24 (or whatever point size) by performing a linear scale of the 10 point face.
This can cause problems. Suppose a document is created on one Macintosh containing a font that only exists in that System file in one point size, say 9 point. The document is then taken to another Macintosh with a System file containing that same font but only in 24 point. The document may, in fact, appear differently on the two screens, and when it is printed, will have line breaks (and thus paragraph and page breaks) occurring in different places simply because of the differences in character widths that exist between the 9 point and 24 point faces.
The Printer Driver
Even when the printer you are using has a much higher resolution than what the screen can show, printer drivers perform line layout to match the screen layout as closely as possible.
The line layout performed by printer drivers is limited to single lines of text and does not change line break positions within multiple lines. The driver supplies metric information to the application about the page size and printable area to allow the application to determine the best place to make line and page breaks.
Printer driver line layout does affect word spacing, character spacing and even word positioning within a line. This may affect the overall appearance of text, particularly when font substitutions are made or various forms of page or text scaling are involved. But print drivers NEVER change line, paragraph or page break positions from what the application or screen specified. This means that where line breaks appear on the screen, they will always appear in the same place on the printer regardless of how the line layout may affect the appearance within the line.
Operating System and ROMs
In this context, operating system refers to the ROM trap routines which handle fonts and QuickDraw. Changes have occurred between the ROMs in the handling of fonts. Fonts in the 64K ROMs contain width tables (as described above) which are limited to integer values. Several new tables, however, have been added to fonts for the newer ROMs. The newer ROMs add an optional global width table containing fractional or fixed point decimal values. In addition, there is another optional table containing fractional values which can be scaled for the entire range of point sizes for any one face. There is also an optional table which provides for the addition (or removal) of width to a font when its style is changed to another value such as bold, outline or condensed. It is also possible, under the 128K ROMs, to add fonts to the system with inherent style properties containing their own width tables that produce different character widths from derived style widths.
One or all of the above tables may or may not be invoked depending on, first, their presence, and second, the mode of the operating system. The Font Manager in the newer ROMs allows the application to arbitrarily operate in either the fractional mode or integer mode (determined, in most cases, by the setting of FractEnable) as it chooses, with the default being integer. There is one case where fractional widths will be used if they exist even though fractional mode is disabled. When FScaleDisable is used fractional widths are always used if they exist regardless of the setting of FractEnable.
Differences in line layout (and thus line breaks) may be affected by any combination of the presence or absence of the optional tables, and the operating mode, either fractional or integer, of the application. Any of the combinations can produce different results from the original ROMs (and from each other).
The integer mode on the newer ROMs is very similar to, but not exactly the same as, the original 64K ROMs. When fonts with the optional tables present are used on Macintoshes with 64K ROMs, they continue to work in the old way with the integer widths. However, on newer ROMs, even in the integer mode, there may be variations in line width from what is seen on the old ROMs. In the plain text style there is very little if any difference (except if the global width table is present), but as various type styles are selected, line widths may vary more between ROMs.
Variations in the above options, by far, account for the greatest variation in the appearance of lines when a document is transported between one Macintosh and another. Line breaks may change position when documents created on one system (say a Macintosh) are moved to another system (like a Macintosh Plus). Variations are more pronounced as the number and sizes of various type styles increase within a document.
In all cases, however, a printer driver will produce exactly the same line breaks as appear on the screen with any given system combination.
Further Reference:
• The Printing Manager
• The Font Manager
• M.IM.LaserWriterOpt
Script Manager 2.0 Date & Time Problems
Text M.TE.ScriptDateTime
Written by: John Harvey February 1990
This Technical Note describes known bugs and features in and solutions to the date and time routines introduced in Script Manager 2.0.
From the beginning, the Macintosh’s ability to handle dates was limited to a rather small range—slightly more than a century. Enhancements to the Script Manager, introduced with System Software 6.0, extended this range to ±35,000 years. Unfortunately, there is a minor bug in one of the crucial calls and a “feature” that looks like a bug in another.
You Said It Would Be A Long Time
_LongSecs2Date, the routine that translates a LongDateTime to a LongDateRec, has a bug caused by using a variable that has not been properly initialized. This bug rears its ugly head when negative values are passed to the routine. System Software 6.0.4 and later fix this bug, and there is a simple solution for earlier systems.
If using System Software 6.0.3 and earlier, if you call _LongSecs2Date once before you really want to use it, the variable is cleared. After the initial call, _LongSecs2Date works correctly.
For example:
MPW Pascal
PROCEDURE DoDateStuff;
VAR
lsecs: LongDateTime;
ldr: LongDateRec;
BEGIN
InitDateCache(dcr);
lsecs := 0;
LongSecs2Date(lsecs,ldr);
{now you can call LongSecs2Date for real}
END;
MPW C
void DoDateStuff()
{
LongDateTime lsecs;
LongDateRec ldr;
/* work around the bug */
lsecs = 0;
LongSecs2Date(&lsecs,&ldr);
/* now call LongSecs2Date for real */
}
Any String To Date
The routine _String2Date was originally designed to be as forgiving as possible. It is so forgiving that it accepts any non-alphabetic character as a separator and accepts a single number as a valid date. For instance, if you pass _String2Date a string like “<20” it generously assumes that the less than sign (<) is intended as a divider and that “20” must be intended as a day, since there are only 12 months in a year. It returns a result of noErr and a date which is the twentieth of the current month in the current year. The string “<3*3” produces March 3 of the current year, while “4>1” politely gives the date April 1 of the current year.
This forgiveness really is not a bug, but a feature. Unfortunately it isn’t a feature that has been greatly appreciated in the developer community. For that reason, the rules for date and time dividers are tighter in System 7.0. Current thinking is that all list separators now used in 'itl0' resources will be allowed with a few common date separators used in the U.S. (e.g., colon (:) and hyphen (-)). For now, it is important to be aware of, shall we say, the flexibility of _String2Date and avoid thinking of it as an intelligent date parser. If you want to parse something, you can use _IntlTokenize.
Further Reference:
• Inside Macintosh, Volume V, The Script Manager
• The Script Manager 2.0, Interim Chapter (DTS)
Drawing Characters into a Narrow GrafPort
Text M.TE.TextInNarrowGP
Revised by: March 1988
Written by: Ginger Jernigan January 1986
When you draw a character into a GrafPort, your program will die with an address error if the width of the GrafPort is smaller than the width of the character. If you check before drawing the character to see if the GrafPort is wide enough, you can avoid this unfortunate tragedy.
Further Reference:
• QuickDraw
Fond of FONDs
Text M.TE.FONDs
Written by: Joseph Maurer May 1992
This Technical Note takes the place of Tech Note #26, “Character vs. String Operations in QuickDraw” by Bryan Stearns (March 1988), which pointed out the possible differences between the results of a StringWidth call and successive calls to CharWidth. This Note updates and brings into a broader context the issues related to text measuring. It also provides additional documentation on font family resources ('FOND's), and addresses various other frequently asked questions related to the Font Manager.
Introduction
Every Macintosh developer needs to draw text in a GrafPort, and to specify typeface, size, and style. In most cases, there are no problems, and application developers don’t need to have in-depth knowledge of the Font Manager’s inner workings and the data structures involved. Sometimes, however, the results on the screen or on printed output may be different from what you expected. Then, usually, DTS comes into play to figure out what the problem is and how to fix it. This Note is based on sharp developer questions from the last year or so, which point mainly at shortcomings of the existing Font Manager architecture, inconsistencies in its data structures, and missing details in the documen-tation.
We’ll start with a historical overview, which discusses the introduction of font family description resources ('FOND's) back in 1986, explains the consequences of non-proportionally scaling fonts, and covers non-registration and volatility of font family numbers.
We will then deal with the Font/DA Mover and the built-in “Mover” of the Finder in System 7. We discuss a number of not-so-well-known aspects of moving fonts in and out of a suitcase file, and recommend that you altogether abandon the resource type 'FONT'. We'll also comment on font names, and show you how to put separate stylistic variants of a typeface together into one font family. And we provide documentation on the ffVersion field of a 'FOND' (accompanied by a disclaimer and another piece of irritating information).
The main body of this Note addresses how the Font Manager works in the FMSwapFont context, and gives information on the scaling factors in the FMOutput structure and on the changes introduced by TrueType. We again took the examples of unexpected behavior (under certain circumstances) from developer questions. Thanks for helping document this!
Determining the width of text, as required for line layout, is sometimes trickier than you might think. We will document the effects of SetFractEnable in more detail and mention some more line layout problems.
Finally, this Note includes sample code that puts the OutlineMetrics call to work, and determines text bounding boxes for bitmap fonts.
Some FOND Background
Originally (Inside Macintosh Volume I, Chapter 7), all font-related data was contained in resources of type 'FONT'. For a font number within the range 0....255, and a font size restricted to less than 128, the (unnamed) 'FONT' resource with an ID:
128*(font number) + (font size)
contained the bitmap font strike, while the 'FONT' resource with ID = 128*(font number), corresponding to font size 0, did not contain any data, but its resource name provided the font family name. QuickDraw took care of stylistic variants like italic, bold, shadow, and so on; if a user had a specifically fine-tuned font strike for a stylistic variant, QuickDraw would not automatically substitute it when drawing text.
For aesthetic reasons, bitmap fonts for different sizes were usually designed with widths non-proportional to the point size. For example, the text “Show the difference in text widths” drawn with Courier 9 measures 170 pixels, whereas the same text drawn with Courier 18 measures 374 pixels, which is 10% more than you expect. (By the way, this is bad news for the ImageWriter printer driver. When “Best” mode (144 dpi) is selected and text in Courier 9 is to be printed, the printer driver uses Courier 18 to render the 9-point font size on the paper at twice the screen resolution, and obviously has big trouble compensating for the 10% difference in text width.)
On the other hand, given that only integer character widths (in QuickDraw’s 72 dpi units) are possible, proportional font scaling is compromised anyway. Accumulated rounding errors in text measuring, particularly for scaled fonts, contribute to the headaches of many Macintosh programmers. The computed text widths (vital for positioning text precisely and for line layout algorithms to justify text) sometimes change quite abruptly when the user removes or adds certain font sizes.
The introduction of the LaserWriter, and the success of Macintosh in the desktop publishing arena, required an extension of the original Font Manager architecture. This extension is based on the concept of “font family description” resources of type 'FOND', and on a new resource type 'NFNT' for the data of the existing 'FONT' resources (see Inside Macintosh Volume IV, Chapter 5).
The 'FOND' resource stores size-independent information about the font family, and its resource ID is the font number (in the range 0...32767). The resource name of the 'FOND' is the font name, and it contains a variable-length font association table, which references the font strikes belonging to a specific font family. These references include size, style, and resource ID of the 'NFNT' or 'FONT' resource containing the bitmap font data. TrueType fonts were retrofitted into this scheme, and are identified as font strike resources for point size zero. Any reference to point size zero refers to a resource of type 'sfnt'.
Note: The range 0...32767 for font numbers is subdivided into ranges for the various script systems (see Inside Macintosh Volume VI, pages 13-8 and 14-22, and M.TE.FontsAndScripts). This restricts the range of font numbers for the Roman script to 0...16383, with 0, 1, and 16383 reserved for the system.
Since Apple originally intended fonts to be referenced by their font family numbers, DTS attempted to register those numbers (see Inside Macintosh Volume I, page 219 and Volume IV, page 31). This failed—not only because the number of fonts registered grew greater than the number of font family numbers available, but also because the Font/DA Mover (version 3.8, shipped with System 6), and the “Mover” built into the System 7 Finder resolve conflicts between font IDs (which happened anyway!) by renumbering the fonts on-the-fly. There is no font ID registration any more—except for the very special case of Japanese Kanji 'FOND'–'fbit' IDs, and potentially for Korean, Chinese and other double-byte fonts.
As early as April 1988, M.IM.FontNames recommended the use of font names rather than font family numbers. Since then, the recommendation has been reinforced in Inside Macintosh Volume VI, page 12-16. Fortunately, most applications have been good about following this recommendation. Unfortunately, some exceptions remain, even in Apple’s own software. QuickDraw Pictures created without 32-Bit QuickDraw refer to fonts by font family number only!
For obvious reasons of upward compatibility (to maintain existing fonts, and to avoid reflowing of existing documents), the introduction of 'FOND's did not solve all the problems. This is what this Note is all about.
Moofing Fonts
The Font/DA Mover utility has evolved into version 4.1, which knows about 'sfnt's. It is available on the Developer CD Series disc, path “Tools & Apps (Moof!): Misc. Utilities:”. The Finder in System 7 incorporates its own “Mover” (see Inside Macintosh Volume VI, page 9-33), which makes the Font/DA Mover redundant for System 7 users.
Given the combinatorial explosion of all imaginable situations with 'FOND's, 'FONT's, 'NFNT's and 'sfnt's, and stylistic variations of fonts belonging to the same family, the font moving job deserves respect. The following notes cover some less well-known aspects of this business.
• If an old “standalone” 'FONT' (without corresponding 'FOND' resource) is moved into a suitcase file, Font/DA Mover or the System 7 Mover creates a minimal 'FOND' resource on-the-fly. This 'FOND' has no tables, and nearly all its fields are zeroed. The System 7 Finder also converts the resource type from 'FONT' to 'NFNT'; unfortunately, the Font/DA Mover keeps the resource type 'FONT'.
Note: While it is perfectly legal to have 'FOND's continue to reference the older 'FONT' type, DTS recommends that you avoid 'FONT's. Accessing 'FONT's is much slower, since the Font Manager always looks for 'FOND's and 'NFNT's first. More importantly, 'FONT's are troublemakers if an application comes with its own font in its resource fork. Imagine an application that includes a private 'FOND' which references a 'FONT' in its resource fork by resource ID. When the Font Manager wants to load the font resource, it first looks for a resource of type 'NFNT' with this same resource ID. If there’s an 'NFNT' in the System file with the same resource ID, the Font Manager will pick it instead of the 'FONT' from the application’s resource fork. This happens more often than you’d like to think!
• Under the current font architecture, the font name is the resource name of the 'FOND' resource (let’s forget about 'FONT's altogether), so the font name can be any Pascal string. Unfortunately, this conflicts with the 31-character limitation of a file name when the System 7 Finder derives the file name of a movable font file (Inside Macintosh Volume VI, page 9-34) from the font name. Some third-party fonts come with font names long enough to cause trouble. You may also see this problem when trying to open a suitcase if the Finder can't generate distinct names for all of the fonts in the suitcase; the Finder may say the suitcase is “damaged” when it is not.
Note: Each TrueType 'sfnt' resource contains a Naming Table (see The TrueType™ Font Format Specification, APDA™ M0825LL/A) which provides nearly unrestricted font naming capabilities, to accommodate the needs of font manufacturers. A forthcoming Macintosh Technical Note on TrueType Naming Tables gives additional information.
• QuickDraw and the current Font Manager have no provision for stylistic variants like “light,” “medium,” “demi,” “book,” “black,” “heavy,” “extra,” “ultra,” etc., used in the context of professional typesetting. Therefore, each of these variants comes with a separate font family resource. Probably for reasons of consistency, the “italic” variants have their own font family resources as well. Unfortunately, unless each 'FOND' references both the “plain” and the “italic” font strikes, QuickDraw will no longer know a customized italic font strike exists.
It is fairly easy, using System 7 and ResEdit, to merge two font families (named, for exmaple, “myFont” and “myFont italic”) into one. This way, QuickDraw will automatically use the pre-designed italic font strike instead of creating one algorithmically. Follow these convenient steps:
1. Make sure there is no resource ID conflict between the 'NFNT's and 'sfnt's belonging to both families.
2. Make sure the style bits for italic are set in the font association table of “myFont italic.”
3. From ResEdit’s File menu, “Get Info...” on the “myFont” 'FOND' resource. Write down the resource ID of the “myFont” 'FOND'.
4. From ResEdit’s File menu, “Get Info...” on the “myFont italic” 'FOND'. Change its resource ID to be identical to the one you wrote down in step 3. Change its resource name to “myFont.”
5. Use the Finder in System 7 to move the contents of the “myFont italic” suitcase into the original “myFont” suitcase. It will merge all constituents into one font association table, and thus enable transparent substitution of the right font for QuickDraw’s italic style.
Version Numbers
The 'FOND' structure (see Inside Macintosh Volume IV, page 45, “FamRec”) contains a field ffVersion, and inquiring minds naturally want to know more about it. Before anything else, however, please read the following disclaimer:
Disclaimer: The Font Manager does not check version numbers in a 'FOND', and we recommend that you not rely on the (intentionally vague) statements below, but rather analyze the data in the 'FOND'independently.
Currently, values 0...3 may appear in the ffVersion field, with the following intended interpretations:
Version 0: Usually indicates that the 'FOND' has been created on the fly by the Font/DA Mover (or the System 7 Finder). But the 'FOND' for Palatino on the distribution disks of System 7 is a counterexample.
Version 1: Obviously indicates the first version when 'FOND's came out (Inside Macintosh Volume IV, page 36).
Version 2: Corresponds to the extension of the 'FOND' format documented in Inside Macintosh Volume V, page 185 (which does not mean that the 'FOND' actually contains a bounding box table).
Version 3: The 'FOND' is supposed to contain a bounding box table.
This brings up an annoying fact. All measurement values (referring to a hypothetical 1-point font) in the 'FOND' are in a 16-bit fixed-point format, with an integer part in the high-order 4 bits and a fractional part in the low-order 12 bits. You would expect that negative values (like for ffDescent, or in the kerning tables) are represented in the usual two’s-complement format, such that standard binary arithmetic applies. This is mostly true, but not always. Again, Palatino is a counterexample (and probably not the only one). To our knowledge, version 0 and version 1 'FOND's have negative values represented in a format where the most significant bit is the sign bit, and the rest represents the absolute value. However, there is nothing in the system software that enforces this, so counterexamples may exist.
Warning: Don’t rely on the version number, but include sanity checks for the negative values in a 'FOND' instead! The following Pascal function shows how this can be done:
FUNCTION Check4p12Value(n: Integer): Integer;
{ n is a 4.12 fixed-point value; i.e., its "real" value is n/4096. }
{ If n is "unreasonably negative," interpret the most significant bit }
{ as sign bit, and convert to the usual two's complement format. }
BEGIN
IF n < $8FFF THEN { means: (4.12-interpretation of n) is below - 7 }
Check4p12Value := - BitAnd(n,$7FFF)
{ i.e., mask sign bit, and take negative of absolute value }
ELSE
Check4p12Value := n;
END;
In the Heart of the Font Manager
Swapping Fonts
As stated in Inside Macintosh, there is only one contact between QuickDraw and the Font Manager: the FMSwapFont function. Each of the three QuickDraw text measuring functions (CharWidth, StringWidth and TextWidth) always ends up in the QuickDraw bottleneck procedure QDProcs.txMeasProc. Each of the three QuickDraw text drawing procedures (DrawChar, DrawString and DrawText) always ends up in the QDProcs.textProc bottleneck procedure. Any reasonable textProc (like StdText) needs to call the currently-installed text measuring bottleneck procedure before actually rendering the text. And what does any reasonable text measuring bottleneck procedure(like StdTxMeas) do first, before anything else? It calls FMSwapFont, to make sure we are talking about the right font and its properties! (To be precise, GetFontInfo and FontMetrics are the other calls that make sure the right font is swapped in and set up, without requiring you to call FMSwapFont explicitly.)
Responding to a font request is a lot of work, and FMSwapFont has been optimized to return as quickly as possible if the request is the same as the previous one. Building the global width table (see Inside Macintosh Volume IV, page 41) is among the more time-consuming tasks related to FMSwapFont; this is why the Font Manager maintains a cache of up to 12 width tables.
Inside Macintosh Volume I, page 220 documents the Font Manager’s choice when a font of the requested size is not available. However, some consequences or additional features have occasionally been a surprise to developers (and users as well).
Scaling Factors in FMOutPut and StdTxMeas
Let’s suppose you have only a 12-point bitmap version of Palatino, and don’t have any Palatino outline fonts. When you request Palatino 18, QuickDraw sets up the FMInput record with size = 18 and numer = denom = Point($00010001).On return, the FMOutput record contains the handle to the font record to use (the 'NFNT' with the Palatino 12 bitmap font strike), and indicates the scaling factors QuickDraw will have to use to produce the desired text point size in FMOutput.numer and FMOutput.denom. In this example, that ratio is 3/2.
Note that these are also the values returned in StdTxMeas (Inside Macintosh Volume I, page 199) if you call the procedure with numer = denom = Point($00010001). Why? Because StdTxMeas calls FMSwapFont, as explained under “Swapping Fonts.” StdTxMeas does not apply these scaling factors to the text it measures. In our example, it would measure Palatino 12 and return numer and denom in the ratio 3/2 to tell you that your application must multiply the results by these values to get the correct measurements for Palatino 18. This has surprised more than one programmer who didn’t expect numer and denom to change!
By the way, the Font Manager always normalizes the scaling factors as fractions numer/denom such that the denominator is equal to 256. In our example, the real numbers returned by FMSwapFont or StdTxMeas are numer = 384 and denom = 256.
Warning: If the scaling factors numer and denom passed to StdTxMeas, StdText (see Inside Macintosh Volume I, pages 198 and 199), or in the FMInput record to FMSwapFont are such that txSize*numer.v/denom.v is less than 0.5 and rounds to 0, and if there is more than one 'sfnt' resource referenced in the font association table, then the current Font Manager may get confused and return results for the wrong font strike.
TrueType Always Has the Right Size
The default value of outlinePreferred is FALSE. If you have bitmap fonts for Palatino 12 and Palatino 14 in your system as well as a Palatino TrueType font, then requests for Palatino 12 or Palatino 14 are fulfilled with the bitmap fonts, but requests for any other size are fulfilled with the TrueType font. In particular, if you (or, for example, a printer driver) need Palatino 12 scaled by 2, the Font Manager will actually look for Palatino 24 and return the outline font, regardless of the setting of outlinePreferred. Even if you wanted the bitmap font doubled for exact “what-you-see-is-what-you-get” text placement, you’re out of luck—you get the TrueType font, which may have very different font metrics or character shapes.
If the Font Manager uses an outline font to fulfill a given font request, the IsOutline function returns TRUE. Interestingly, this does not imply that RealFont returns TRUE as well. If the text size is smaller than the value lowestRecPPEM (“smallest readable size in pixels”) in the 'head' font header in the TrueType font (see The TrueType Font Format Specification, version 1.0, page 227), then RealFont returns FALSE!
First Size, Then Style—or: To Be or Not to Be Outline
When the Font Manager walks the font association table of a 'FOND' to look for a font strike of a specified size and style, it stops at the first font of the right size. Only if you requested a stylistic variant (like bold or italic) does it take a closer look at the fonts of the same size. It does this by putting weights on the various style bits (for example, 8 for italic, 4 for bold, 3 for outline) and choosing the font strike whose style weight most closely matches the weight of the requested style. All this is fine when only bitmap fonts are available. With the presence of TrueType outlines, however, the results are not always as expected, depending on the font configuration installed.
Let’s look at a few examples:
Example 1: Let’s suppose you have the bitmap font Times 12 (Normal) and the TrueType fonts Times (Normal), Times Italic and Times Bold in your system. If you request Times 14 Italic or Times 14 Bold, it’s rendered from the Times Italic or Times Bold TrueType fonts. However, if you ask for Times 12 Italic or Times 12 Bold, and your system has the default setting of outlinePreferred = FALSE, the Font Manager decides to take the Times 12 bitmap and let QuickDraw algorithmically slant it (for italics) or smear it (for bold).
Example 2: Let’s suppose you want to draw big, bold Helvetica characters and there are no existing bitmaps for the size you want. If the Helvetica Bold TrueType outlines are available, the Font Manager chooses them and the only surprise in text rendering will be a pleasant one. If there is no Helvetica Bold TrueType font, however (like in the machine of your customer, who kept only the normal Helvetica TrueType font in his system), then the characters are rendered using the normal Helvetica outlines and, in a second step, QuickDraw applies its horizontal 1-pixel “smearing” to simulate the bold stylistic variant. The result is very different (and rather an unpleasant surprise).
Example 3: Admittedly, this is less likely (but it has happened). Let’s suppose somebody decides to rip the Times TrueType outline out of the System file (don’t ask me why—I don’t know). He forgets to take the Times Italic TrueType outline away as well. The next time he draws text in Times (Normal), in a size for which there is no bitmap font (or if outlinePreferred = TRUE), the Font Manager goes for an 'sfnt', and the text shows up in italic (what a surprise!).
Unfortunately, given the current implementation of the Font Manager, there are no solutions to the problems illustrated above—other than asking users of your application to install the fonts you recommend. The only way to anticipate these potential surprises from within your application is to look into the 'FOND's font association table. You can’t depend on the IsOutline function because it returns TRUE as soon as the Font Manager stops at an 'sfnt', in its first pass through the font association table—regardless of subsequent stylistic variations. This means, for example, if you ask for Helvetica Bold and IsOutline returns TRUE, you don’t know if you got the Helvetica Bold TrueType font or if QuickDraw “smeared” the Helvetica (Plain) TrueType font.
Where Do the Widths Come From?
Text measuring (for example, for precise text placement in forms with bounding boxes) and most line layout algorithms for justified text rely heavily on the character widths contained in the global width table. Given that under the current font architecture, we may easily have three or more different width tables for the same font specification (the non-proportional integer widths attached to the 'NFNT', the fractional widths contained in the 'FOND', and the fractional widths provided by the 'sfnt'), it is important to understand where the widths come from in any case.
Since SetFractEnable was introduced (Inside Macintosh Volume IV, page 32 and Volume V, page 180), its setting TRUE or FALSE was supposed to give predictable effects. If it’s FALSE, the Font Manager takes the integer widths from the 'NFNT'; if it’s TRUE, it takes the fractional widths from the 'FOND'. Unfortunately, there are some additional details and side effects that are not well known.
• The Font Manager looks at bit 14 of the ffFlags field in the 'FOND' (see Inside Macintosh Volume IV pages 36 and 37). If it is set (like it is for Courier), the fractional widths from the 'FOND' are never used.
• If SetFractEnable is TRUE and you request a stylistic variation like bold or italic, the Font Manager looks at bits 12 and 13 of the ffFlags field to decide how different widths or extra widths for the stylistic variants have to be used. What it decides is documented in the “Font Manager” chapter of Inside Macintosh Preview, located on the Developer CD Series discs.
• Given that it is not possible to set the pen to a fractional position, precise text positioning with fractional widths enabled is always compromised because of (accumulated) rounding errors.
• QuickDraw distributes the accumulated rounding errors across characters within a string (instead of adding it at the end of the drawn text). This results in poor text quality on the screen, and in problems when calculating the position of the insertion point between characters.
• The LaserWriter driver watches what you pass to SetFractEnable. Passing TRUE to SetFractEnable disables some of the LaserWriter driver’s line layout features, assuming that the programmer intends to control text placement manually. Explicitly passing FALSE to SetFractEnable achieves different results than using the default value of FALSE—Font Substitution behaves differently, for example. These effects are sometimes Not What You Wanted.
• On non-32-Bit-QuickDraw systems, SetFractEnable is not recorded in pictures. This affects the line layout of text reproduced through DrawPicture if the picture was created with fractional widths enabled.
In systems with TrueType, quite naturally the widths always come from the 'sfnt' when the Font Manager uses a TrueType font. If fractEnable is FALSE, hand-tuned integer character widths for specific point sizes come from the 'hdmx' table in the 'sfnt'. If fractEnable is FALSE and no 'hdmx' table is present or it contains no entries for the desired point size, the fractional character widths from the 'sfnt' are rounded to integral values.
More Line Layout Problems
The routines SpaceExtra (Inside Macintosh Volume I, page 172) and CharExtra (Inside Macintosh Volume V, page 77; available only in color GrafPorts) are intended to help you draw fully justified text. This works fine on the screen, but not all printer drivers are smart enough to use these settings appropriately under all circumstances. In particular, if you pass TRUE to SetFractEnable, or if you turn the LaserWriter driver’s line layout algorithm off (by means of the picture comment LineLayoutOff; see Macintosh Technical Note #91), or if font substitution is enabled and actually occurs, it is better not to rely on SpaceExtra and CharExtra when printing fully justified text. Instead, keep the LaserWriter driver’s line layout adjustments off, and calculate the placement of your text (word by word, or even character by character) yourself.
Putting Text Into Boxes
TrueType fonts came to the Macintosh together with seven new Font Manager routines (as documented in Inside Macintosh Volume VI, Chapter 12). The OutlineMetrics function is certainly the most sophisticated of these, and sample code illustrating its usage may be helpful. The following procedure DrawBoxedString assumes that the new outline calls (Inside Macintosh Volume VI, Chapter 12) are available, and that IsOutline returns TRUE for the current port setting.
PROCEDURE DrawBoxedString(pt: Point; s: Str255);
{ Draw string s at pen position (pt.h, pt.v), and show each character's bounding box. }
CONST
kOneOne = $00010001;
VAR
advA: FixedPtr;
lsbA: FixedPtr;
bdsA: RectPtr;
err,i,yMin,yMax,leftEdge,temp: Integer;
numer,denom: Point;
advance,lsb: Fixed;
r: Rect;
BEGIN
numer := Point(kOneOne);
denom := Point(kOneOne); { unless you want to draw with scaling factors
.... }
MoveTo(pt.h,pt.v);
DrawString(s);
{ This is for the pleasure of your eyes only — in practice, you would probably }
{ first look at the metrics, and then decide where and how to draw the string! }
{ Add accumulated advanceWidth and leftSideBearing of current glyph }
{ horizontally to starting point. }
leftEdge := pt.h + Fix2Long(advance + lsbA^);
r := bdsA^; { The bounding box rectangle is in TrueType coordinates. }
temp := r.bottom; { need to flip it "upside down" }
r.bottom := - r.top;
r.top := - temp;
OffsetRect(r,leftEdge,pt.v);
FrameRect(r); { This is the glyph's bounding box. }
advance := advance + advA^;
{ "Advance" is Fixed, to avoid accumulation of rounding errors. }
{ Now, bump pointers for next glyph. }
bdsA := RectPtr(ord4(bdsA) + SizeOf(Rect));
advA := FixedPtr(ord4(advA) + SizeOf(Fixed));
lsbA := FixedPtr(ord4(lsbA) + SizeOf(Fixed));
END;
DisposPtr(Ptr(advA));
DisposPtr(Ptr(lsbA));
DisposPtr(Ptr(bdsA));
END; { DrawBoxedString }
OutlineMetrics exists because many developers need pixel-precise information on placement and bounding boxes, often on a character-by-character basis. Unfortunately, there is no similar facility for text drawing with bitmap fonts. Worse, under certain circumstances, italicized or shadowed (or both) bitmap fonts are sometimes poorly clipped, particularly for scaled sizes. Cosmetic workarounds include adding a space character to strings drawn in italic. You might also draw the text off-screen first (in order to determine the bounding box of the black pixels) and use CopyBits to copy the text onto the screen—but using CopyBits for text is usually bad for printing.
The existing documentation on the FMOutput and global width table structures (Inside Macintosh Volume I, page 227 and Volume IV, page 41) suggests it’s possible to devise a routine for determining a fairly precise text bounding box for bitmap fonts. The procedure below, BitmapTextBoundingBox, is a first attempt. It assumes that TrueType is unavailable, or that the IsOutline call returned FALSE for the current port settings. While the returned bounding box is not always “tight,” be careful before modifying the algorithm and shrinking the resulting bounding box—bitmap fonts just don’t contain enough precise information for an exact bounding box, and different bitmap fonts and different sizes may require different adjustments.
PROCEDURE TextBoundingBox(s: Str255; numer,denom: Point; VAR box: Rect);
CONST
FMgrOutRec = $998; { FMOutRec starts here in low memory }
tabFont = 1024;
{ global width table offset for font record handle, see IM IV-41 }
TYPE
FontRecPtr = ^FontRec;
VAR
hScale,vScale: Fixed;
err,intWidth,kernAdjust: Integer;
xy: Point;
info: FontInfo; { only for StdTxMeas; we'll use FontMetrics }
At the time when the original Font Manager architecture was designed, based on QuickDraw’s hard-coded 72 dpi resolution, nobody could anticipate that some years later, the Macintosh would be used to tackle professional typesetting projects. Several advanced page layout applications managed to work around the “built-in” limitations, at high development costs, and some compatibility and performance problems. In many other cases, however, those limitations caused questions to DTS and unsatisfying compromises. This Note can’t do much more than explain the state of affairs; the real solution to the problems must come from a redesigned foundation. TrueType leads the way and already fulfills many of the requirements; everything else is getting closer and closer.
Further Reference:
• Inside Macintosh, Volume I, Chapter 7, The Font Manager
• Inside Macintosh, Volume IV, Chapter 5, The Font Manager
• Inside Macintosh, Volume V, Chapter 9, The Font Manager
• Inside Macintosh, Volume VI, Chapter 12, The Font Manager
• New & Improved Inside Macintosh, Imaging: The Font Manager. Developer CD Series disc, path Developer Essentials: Technical Docs: Inside Macintosh Previewf
• Macintosh Technical Note #91, Picture Comments—The Real Deal
• M.IM. FontNames
• M.TE.FontsAndScripts
• M.IM.FontFamilies
• Apple LaserWriter Reference, Chapter 2, Working With Fonts ( Addison-Wesley, 1988)
• Adobe Technical Note #0091 (PostScript Developer Support Group), Macintosh FOND Resources
PostScript and Adobe are registered trademarks of Adobe Systems Incorporated.
Helvetica and Palatino are registered trademarks of Linotype AG and/or its subsidiaries.
Velocio is not a trademark of the author.
Font Manager Q&As
Text M.TX.FontMgr.Q&As
Revised by: Developer Support Center October 1992
Written by: Developer Support Center October 1990
This Technical Note contains a collection of Q&As relating to a specific topic—questions you’ve sent the Developer Support Center (DSC) along with answers from the DSC engineers. While DSC engineers have checked the Q&A content for accuracy, the Q&A Technical Notes don’t have the editing and organization of other Technical Notes. The Q&A function is to get new technical information and updates to you quickly, saving the polish for when the information migrates into reference manuals.
Q&As are now included with Technical Notes to make access to technical updates easier for you. If you have comments or suggestions about Q&A content or distribution, please let us know by sending an AppleLink to DEVFEEDBACK. Apple Partners may send technical questions about Q&A content to DEVSUPPORT for resolution.
New Q&As and Q&As revised this month are marked with a bar in the side margin.
Chicago Control-Q prints propeller or clover symbol
Written: 7/4/90
Last reviewed: 8/1/92
How do I get the character that represents the clover used for command-key equivalents in documents and in menus?
___
This key is documented in the Apple Style Guide, which is available on the latest Developer CD Series disc as well as from APDA. One little feature of Key Caps which is not widely known is the Control key (not the Command or Option keys). Pressing the Control key in Chicago shows that Control-Q in Chicago maps to the propeller symbol for which you search. Control-Q generates the character code 17; the standard Macintosh character set (see Inside Macintosh Volume VI, page 12-5) specifies this symbol for it.
Determining Macintosh system font size
Written: 2/11/91
Last reviewed: 8/1/92
How does a program determine the default system font size?
___
If you want to know the default system font size, use the GetDefFontSize call (Inside Macintosh Volume V, page 314). This call will return the true default system font size. On all Roman systems the sysFontSize low-memory global is always zero by default; this means that it’s actually 12. Don’t ask me why they did this, but it’s true, so you should use the call if you want a painless method of obtaining this information. Try to avoid reading the global directly.
FScaleDisable and Macintosh screen rendering
Written: 6/4/91
Last reviewed: 8/1/92
What is the current interface guideline on font scaling? Should we set FScaleDisable to true or false for screen rendering? I believe the old guideline was to set it to true (thus disabling font scaling) so that if you have a 23 pt screen font you will see 12 pt glyphs with 23 pt widths. We want performance on Apple’s low-end machines, and we don’t want to make this a user preference.
___
Most applications now set FScaleDisable to false all the time. If you are worried about the speed degradation in your application when running on slower Macintosh systems, you could have your software identify which Mac it is running on using Gestalt, SysEnvirons, etc., and then set FScaleDisable to true only on the slow machines. From the purely interface point of view, “what-you-see-is-what-you-get” is best, if processor speed allows it.
With TrueType there is no issue, since FScaleDisable doesn’t have any effect on an outline font.
Macintosh double-byte character encoding
Written: 8/5/91
Last reviewed: 8/1/92
When will System 7 and TrueType be able to support a larger character encoding vector than the current 256 characters? Is this something I could do now?
___
System 7 does not have double-byte character encoding support now. In the future, Apple will use the two-byte UNICODE standard for its operating systems. However, such a change will be huge and therefore will not be available in the near future.
Ever since 6.0.2, KanjiTalk has had double-byte encoding, so you can use the Japanese system at this time. The system which allows you to do this is called shift-JIS (Japanese Input System). The mappings are on the current Developer CD in the Kanji folder.
'FOND' resource features subject to change
Written: 6/17/91
Last reviewed: 8/1/92
Which 'FOND' features are subject to change, and what parts can I rely on?
___
'FOND' features not documented in Inside Macintosh, Macintosh Technical Notes, or develop are subject to change. That’s the official word.
Five font style-mapping table styles
Written: 6/17/91
Last reviewed: 8/1/92
Why is “47” the bounds of the indexes’ array in the StyleTable?
___
The style-mapping tables, which are used for mapping of a font style to a particular font for printing, have only five possible styles, unlike the six screen styles (underline is omitted, since a laser printer just explicitly draws a line under the string—it doesn’t need a special font for that). You can have any combination of these five styles, EXCEPT that you can’t have “Condense” and “Extend” at the same time (Condensed Extended wouldn’t make a whole lot of sense). Thus you get (combinatorics come back to haunt us) 48 possible unique styles to map to.
We ship modified versions of the Chicago and Geneva fonts and their FONDs in our application’s resource fork. With System 6, when we ask for font 0 or font 3, we get our modified fonts in windows, buttons, menus and dialogs, but not with System 7. Is there a new way to tell System 7 to use my version of Chicago 12 to display all system related stuff?
___
What’s happened is that the system software is being much more strict about whose “Chicago” it uses for menus and dialogs. The Menu and Control Managers now only look at the system file for the Chicago they use.
There are a couple of ways to get around this: First, you can try patching DrawString right before calling MenuSelect in your program. The patch would select your Chicago and then jump to the standard DrawString. After MenuSelect, remove the patch. The disadvantage of this method is that, if a future system software release doesn’t use DrawString for drawing menus, the patch would cease to have any effect.
A better solution is to write your own menu and control definition code—in other words, your own custom MDEF and CDEFs. The way you typically do this is to get a copy of the standard Macintosh system’s MDEF or CDEF, and alter it to your specifications. In your case, this would be merely selecting your font instead of the system font. Name your font something other than Chicago and just select that font by name in the menu or control’s draw routine. The Control and Menu Manager chapters in Inside Macintosh Volume I have more information on writing custom definitions. There is only one problem with this right now: While the System 6 MDEF and CDEF are available on AppleLink, the System 7 versions are not available yet, although they will be soon.
A note on the use of Chicago in your application: As the June 1991 edition of the Macintosh Technical Note “Font Family Numbers” mentions, fonts are copyrighted material. Apple owns the Chicago font and typeface, so be sure you check into licensing issues before releasing any version, altered or unaltered, with your application.
Spanish typographic measurements
Written: 12/10/91
Last reviewed: 8/1/92
What typographical measurement issues must be considered for Spanish systems? Do the Spanish specify type in ciceros and didots instead of points?
___
If typesetting is done in Spain with computers, U.S. standards generally are used. It is only when typesetting is done the old-fashioned way that you’ll see different measurements.
Paper sizes are different. In Spain DIN-44 (210 x 297), DIN-A3 (420 x 297) and “folio” (215 x 315) are used. As always, you’ll be working with 72 dpi for the screen (and any time you use QuickDraw) but something different on paper, so you’ll need to use PrGeneral and image the stuff yourself to a resolution that allows you control over your imaging for printing. This is detailed in the article, “Meet PrGeneral, the Trap That Makes the Most of the Printing Manager,” in issue #3 of develop.
Here are the measurements used in Spain:
• Decimal point (Didot) (0.3759 mm)
• Millimeter
• Cicero (12 decimal points)
• Centimeter
• Inches
SetOutlinePreferred = TRUE or not?
Written: 12/2/91
Last reviewed: 8/1/92
My application calls SetOutlinePreferred so outline fonts are used if both bitmapped and TrueType fonts are in the system. It was reported to me, however, that some international TrueType fonts in particular look really bad at small point sizes on the screen. Should I avoid calling this function?
___
SetOutlinePreferred is best used as a user-selectable option. Along the same lines, you might want to include the SetPreserveGlyph call (Inside Macintosh Volume VI, page 12-21), again, as a user-selectable option.
Currently, as you know, the default for outlinePreferred is FALSE; this is for compatibility reasons (existing documents don’t get reflowed if the bitmap fonts are still around) and for esthetic and performance reasons (users are free to maintain bitmap fonts in the smaller point sizes if the TrueType version is not satisfying for small sizes, or too slow). On the other hand, as soon as a bitmap font is *un*available for a requested point size, and an outline font is present, the outline font is used even with outlinePreferred = FALSE. Setting outlinePreferred = TRUE makes a difference only for point sizes where a bitmap font strike is present along with a 'sfnt' in the same family/style.
TrueType fonts might be preferable even for small point sizes if linearly scaled character widths are more important than screen rendering: If the main purpose of a program is preprint processing for a high-resolution output device, then outlinePreferred = TRUE may give better line layout results on the printer, at the price of “not so great” type rendering on a 72 dpi screen. (An example for the conflict between linearly scaling TrueType and non-linearly scaled bitmap fonts is Helvetica: StringWidth('Lilli') returns 19 for the 12-point bitmap font, and 15 for the 13-point size from TrueType!)
All this boils down to the recommendation stated initially: The user should be given the flexibility to decide whether to use the existing bitmaps (using TrueType only for bigger point sizes and high-resolution printers), or to go with TrueType even if the result on the screen is not optimal. (By the way, it’s likely that TrueType development will substantially reduce this conflict in the future.)
FontRec fontType field and determining monospaced fonts
Written: 1/13/92
Last reviewed: 8/1/92
How can I create a menu that contains only fixed width fonts? The FontRec record’s fontType field doesn’t correctly tell me if the font is fixed width as Inside Macintosh Volume V says it should. All system fonts appear to have the same fontType regardless of whether they are fixed or proportional. Currently I test if the width of the characters “m” and “i” are equal and if they are, I consider the font to be fixed width. Is there an easier (and faster!) way?
___
The Font Manager documentation is not explicit enough about the fact that bit 13 (0x2000) of the fontType field is basically useless. Neither does the Font Manager check the setting of this bit, nor does QuickDraw (or any printer driver). As you observed, monospaced fonts like Monaco or Courier don’t have the bit set; so the meaning of this bit is just perverted to nonsense—sorry! In addition, the fontType field only is available for 'FONT's and 'NFNT's; it does not exist in 'sfnt's, and you would have to check separately for the resource type of the font.
Your idea of comparing the widths of “m” and “i” (or any other characters which are extremely unlikely to have the same widths in a proportionally spaced font) is indeed the only reasonable way of figuring out if a font is monospaced.
Getting global width table for a font specification
Written: 4/22/92
Last reviewed: 8/1/92
What’s the fastest way to get the width table for a given font? FontMetrics is too slow, especially in color. Is there any other call that will get the global width table set up correctly? That is all that we need from the call to FontMetrics.
___
FontMetrics does not have much overhead in setting up the width table. It does a dummy DrawChar(' '); this is very rapidly transformed into a call to StdText, and StdText immediately calls StdTxMeas. The first thing StdTxMeas does is to set up the input parameters for a FMSwapFont call and call it. FMSwapFont is the heart of the Font Manager, and does all the work. It comes back with the FMOutput record, the font strike, and the width table. From there, FontMetrics derives the values it needs to bring back.
You probably wouldn’t save much more than 1/1000th of a second if, instead of calling FontMetrics, you called FMSwapFont explicitly yourself—our only alternative suggestion.
The Font Manager does quite a lot of caching (up to 12 width tables), and managing the cache takes some cycles, too. If there is nothing in the cache corresponding to the font request, the cache makes the call even slower than it would be without cache.
The next source of overhead is the Resource Manager. Looking for a specific font involves going through the whole resource chain first for the FOND (if none is found, the search restarts for a FONT), and then, based on the FOND’s font association table, for a NFNT or 'sfnt'. If no NFNT is found, the search restarts for a FONT, always through the whole resource chain. For a huge resource fork like in the System file (and, maybe, also in your application), the time spent in the Resource Manager is not negligable—in particular, if you have add-ons in your system (such as INITs or 'cdev's) that patch out Resource Manager calls, maybe several times, and usually slow it down considerably!
Even in case this hurdle is overcome swiftly (after all, the Resource Manager has its own caching scheme for optimization), the next step necessarily takes some time, and, as you have observed, especially on a color system: It consists of actually providing the bitmap for the font strike. If the screen depth is >1, this involves creating “synthetic” fonts for the correct screen depth, to optimize text drawing. Also, if the font is an outline font, the first time a font strike has to be rasterized is quite costly in terms of machine cycles.
Finally, the width table can be created; and, because of the scaling factors involved, this requires 256 times some arithmetic which is known never to be fast enough.
All this certainly gives us an understanding for the time it takes FMSwapFont (FontMetrics) to get the job done, but it does not solve your problem.
Depending on how predictable the usage of fonts and width tables in your application is, you might consider building kind of a database of width tables beforehand, or along the way, and use this information directly from within your application. There is no shortcut at all through the Resource Manager to get at the font resources, and there is no shortcut within FMSwapFont, like not building the font bitmaps. (To the best of my knowledge, the needbits field in the FMInput record does *not* have this effect.) The only obvious way to get width tables faster is to keep them around, and to extend manually the capacity of the Font Manager’s cache of width tables.
SetFractEnable and recalculating width tables
Written: 5/5/92
Last reviewed: 8/1/92
Calling SetFractEnable seems to force the width tables to be recalculated regardless of the setting of the low-memory global FractEnable. We’re calling this routine at a central entry point for any document, as it’s a document by document attribute. We then unconditionally call SetFractEnable(false) on exit back to the event loop, to be nice to other applications. Calling SetFractEnable(false), seems to trigger the recalculation even though FractEnable is false. What’s the best way to get around this?
___
Your observation is correct. The SetFractEnable call stuffs the boolean parameter (as a single byte) into the low-memory global $BF4 and indiscriminately invalidates the cached width table by setting $B4C (LastSpExtra) to -1 (LongWord = Fixed). Obviously, it was not anticipated that SetFractEnable could be called quite regularly with a parameter that often does not change the previous setting. (By the way, the same observation applies to the SetFScaleDisable call).
In your case, you may want to replace the SetFractEnable call by your own test of the boolean (8-bit) in $BF4 (FractEnable), and call SetFractEnable only if the parameter passed is different from the value stored in $BF4. Note that Inside Macintosh Volume IV (page 32) explicitly allows you to hack the $BF4 location directly, so it’s unlikely there are any future compatibility problems if you go your own way around the original SetFractEnable. The only additional information you need is what’s mentioned above: The Font Manager always checks $B4C (LastSpExtra) for -1 before doing anything with the global width table; if it finds ($B4C) = LongInt(-1), it painfully rebuilds the width table.
Another comment: You do not need to think of other applications when resetting FractEnable; in a context switch to another application, all low-memory globals are swapped anyway. Still, the above optimization of SetFractEnable probably is useful even when you don’t call it any more systematically on exit to the event loop.
Corrupted Macintosh font or font suitcase criteria
Written: 6/19/92
Last reviewed: 9/15/92
I would like to be able to detect whether a font suitcase is corrupted when it is opened and whether any of the fonts in it are corrupted before any of the fonts are used. I know that the Finder is able to do this, and I was wondering if Apple gives out this information. My program will only run under System 7.0 if that helps. Any information that you can give me would be greatly appreciated.
___
The Finder and the type architecture are living things; the definition of what is and is not a damaged suitcase can change from release to release of system software. However, any of the following conditions makes System 7.0 report the suitcase as “damaged”:
• More than eight FONDs reference the same font.
• A new stand-alone object can’t be created for a font icon. The usual cause of this is that two FONDs have the same name for the first 31 characters, and the Finder thinks there’s already an icon in that window with the same name. (Two icons in the same directory with the same name is a sign of damage.)
• There must be at least one font association table entry, and the table can’t go past the logical end of the resource.
• The first resource name in the map must not be zero-length (which is a test for some older third-party corrupted suitcases).
• The FOND must have a name.
• The FOND must have a valid character range—the first character has to be less than the last character—unless it is a "dummy" FOND (created on the fly for old standalone FONTs; in this case, last character = 0).
• All the font association table entries must be in ascending point size order.
• No two font association table entries may reference exactly the same point size and style.
• The offsets to the width table, kerning table and style mapping table must be valid or zero.
• The font ID must not be zero unless it’s actually the system font.
We can’t promise this is every reason the Finder would report a suitcase as damaged (especially given the second step), but this is most of them.
Fonts and the Script Manager
Text M.TE.FontsAndScripts
Written by: John Harvey & Peter Edberg June 1989
This Technical Note describes how the Script Manager uses the font family ID to determine a script code.
The traps _FontScript, _IntlScript, and _Font2Script all use a font family ID to determine the script interface system code that they return. This Note describes the process, the way the Script Manager renumbers the Chicago font for non-Roman systems, and the equation for calculating Script IDs from font family IDs.
On a Roman system the Chicago 'FOND' is numbered zero, but this causes no confusion since Chicago is also the system font. Non-Roman systems must renumber Chicago so that it will not interfere with the mapping of 'FOND' ID = 0 to the correct system 'FOND'. Typically Chicago is renumbered to 16383.
In Inside Macintosh, Volume V-293, The Script Manager, the descriptions of _FontScript, _IntlScript, and _Font2Script state that the current font identification number (e.g., 'FOND' ID) is used to calculate the correct script code. The equation for calculating script codes from 'FOND' IDs is as follows:
script =((FONDid - $4000) DIV 512) + 1
For a specific example, consider the Kyoto font which is one of the fonts included in KanjiTalk. Its 'FOND' ID is 16385. Plugging that value into the equation above, we get: script = ((16385-16384) DIV 512) +1. Which results in a value of one, the script code for the Kanji script system.
Note that this means that script systems other than Roman can only have 512 separate font families. Furthermore, Roman font families (FOND) must not have an ID greater than 16383, and 'FOND' ID 16383 is reserved for Chicago on non-Roman systems.
So How Do They Work?
_FontScript, _IntlScript, and _Font2Script begin by setting two Script Manager globals, Forced and Default to false. Then the two special font family ('FOND') numbers zero and one are mapped to the System and Application font.
Next the 'FOND' ID is tested to see if it is an international font. _FontScript and _IntlScript simply take the value out of the txFont field of the current grafPort. _Font2Script uses the value passed to it. The test is simply:
IF FONDid < $4000 {16384}
script is Roman so return 0
ELSE
script is international so calculate script id using equation described above
Once the script code has been determined, the routine looks at the the Script Manager globals FontForce and IntlForce.
If the currently installed script is Roman and fontForce is true, or if intlForce is true and the routine called was _IntlScript, then the value returned will be the current system script. If the installed script is not Roman; the script code calculated will be returned when the routine called was _IntlScript, intlForce is true, and the script code does not equal the system script.
Once the script code to be returned as been calculated, a final check is made to be sure that the script is installed and enabled. If it is not; Roman is returned, and Forced is set to false and Default is set to true.
What’s This Forced Stuff?
Two Script Manager globals, fontForce and intlForce, are flags that support compatibility. Turning fontForce on will cause Roman fonts to be interpreted as belonging to the system script. This provides compatibility for applications that hard-code font numbers.
For example, the Arabic script interface system provides a cdev which lets a user turn fontForce on. When a user does this, any Roman fonts will be mapped to an Arabic font. Note this is only a partially effective measure since the user still does not have complete control over fonts.
It should also be noted that if a user sets fontForce on via the cdev, values returned for fonts with family IDs in the range $0002 to $3FFF (Roman 'FOND' ID range) may vary. This is not a good feature for applications that allow mixed text. To avoid this problem, an application can turn the fontForce flag off before calling _Font2Script or _FontScript. The flag value should be saved before turning it off, and restored later.
The intlForce flag determines how the call IUGetIntl behaves. If this flag is on, IUGetIntl will always return the international resources ('itlx' where x is 0-2) corresponding to the system script. When intlForce is off, the font in the current port will be used to determine which international resources will be returned. This flag lets an application control what date formats, sorting routines, etc. will be used.
For that reason, before calling any of the international utility routines or using the binary to decimal routines, an application should verify that thePort and thePort^.txFont are set correctly, or that intlForce is set properly.
Let’s Look at a Picture
The flowchart in Figure 1 illustrates the operation of _FontScript, _IntlScript, and _Font2Script, and how they are affected by the global flags fontForce and intlForce.
Figure 1–Operation Flowchart
Further Reference:
• Inside Macintosh, Volume I-493, The International Utilities Package
• Inside Macintosh, Volume V-293, The Script Manager
• Inside Macintosh, Volume V-287, The International Utilities Package
International Resource Q&As
Text M.TX.IntlRsrc.Q&As
Revised by: Developer Support Center October 1992
Written by: Developer Support Center October 1990
This Technical Note contains a collection of Q&As relating to a specific topic—questions you’ve sent the Developer Support Center (DSC) along with answers from the DSC engineers. While DSC engineers have checked the Q&A content for accuracy, the Q&A Technical Notes don’t have the editing and organization of other Technical Notes. The Q&A function is to get new technical information and updates to you quickly, saving the polish for when the information migrates into reference manuals.
Q&As are now included with Technical Notes to make access to technical updates easier for you. If you have comments or suggestions about Q&A content or distribution, please let us know by sending an AppleLink to DEVFEEDBACK. Apple Partners may send technical questions about Q&A content to DEVSUPPORT for resolution.
New Q&As and Q&As revised this month are marked with a bar in the side margin.
Determining the language being used to enter text
Written: 11/20/90
Last reviewed: 8/1/92
Is there a way to tell what language is being used on the Macintosh? I know how to find the script and other international items, but the language being spoken would be a very useful thing to know.
___
It depends on what you mean by “language.” It’s impossible to determine what language the user is typing in without doing a high-level analysis of what is being typed, as you probably know.
One way that’s been suggested in the past is to check on the current KCHR by calling GetScript with an smScriptKeys verb. This returns the resource ID of the currently active KCHR. All international systems come with a U.S. KCHR and possibly others, such as the Romaji and Kana KCHRs in the Japanese systems and the alternative Roman KCHRs in the various German and French systems. The thought was that the user will most likely choose the U.S. KCHR to type in English, and choose the French KCHR to type in French. One problem with this is that it isn’t necessarily true. You can type English with the French KCHR and you can type French with the U.S. KCHR, and many people do. A much larger problem is that the KCHR IDs aren’t standardized within a script system range. Because Apple defines a range of resource IDs for each script system for the international resources, you can tell what script system a KCHR is for, and you can even match up the KCHR ID with the standard KCHR IDs that Apple defines, but there’s nothing wrong with someone creating their own KCHR and giving it any ID they want, as long as it’s in the proper range for the script system they’ve written it for. If that’s the currently active KCHR, its resource ID tells you what script system it’s for, but it won’t tell you anything about what language it was intended for. For this reason, this method is frowned upon now.
In fact, there really is no reliable way of knowing the language that’s being used. The best you can do currently is to find out what the system is localized for. This is done by grabbing the vers resource ID 1 from the System file. In this resource is what was called the country code (the term “country code” is obsolete, in favor of “region code”) which indicates what region the system is localized for. These region codes are defined in Packages.p in MPW, and have names like verUS and verFrance and the like.
There’s another way that you might want to consider. One of the GetScript verbs is smScriptLang. This returns the language code of the specified script system for the current system. If you pass smRoman as the script code to GetScript, it’ll return langFrench on a French system, langGerman on a German system, langEnglish on a U.S. or U.K. or Australian system, and so forth. If you pass smJapanese as the script code to GetScript, it’ll return langJapanese. Interestingly, if you pass smRoman as the script code to GetScript when a Japanese script system is running, it’ll return langEnglish. All non-Roman script systems return langEnglish if you pass smRoman as the script code to GetScript. The language constants are in Language.p in MPW. You’ll probably what to combine this GetScript call with a call to GetEnvirons to find out what the currently active script is. It might look something like this:
(* Get the currently-active keyboard script *)
keyboardScript := GetEnvirons (smKeyScript);
(* Now get the language that the keyboard script corresponds to *)
In summary, there’s no system support for retrieving the language that the user is typing, nor is there any reliable support for retrieving the language related to any KCHR. But, you can find the region code of the active system, and you can find the language associated with the active script. Hopefully, that’s enough information to be useful to you.
RelString & EqualString vs International Utilities
Written: 1/25/91
Last reviewed: 8/1/92
What is the difference between RelString and the EqualString? What does DTS suggest its Macintosh developers use when sorting? Or do you suggest having an option for the international sort?
___
RelString and EqualString are mainly intended for the File Manager. The File Manager uses them for quick-and-dirty string comparison so that it knows how to return files ordered alphabetically when you use an indexed File Manager routines and so that it can detect file name collisions. Beyond that, RelString and EqualString aren’t localizable and they’re not extensible.
The International Utilities string comparison routines are localizable and extensible. They use information in the active 'itl2' resource to determine how the characters are sorted. Most localized systems come with their own 'itl2' resource, and so string comparisons are done correctly for the region that the system is localized for. RelString and EqualString stay the same for all these regions, and so you’ll probably find some cases in which strings are compared incorrectly by these routines.
One important place where RelString and EqualString don’t work very well is with the new characters in the extended Macintosh character set. When the LaserWriter was introduced, the LaserWriter fonts used the extended Macintosh character set which added many new characters, including several new upper-case characters with diacriticals. In system software version 6.0.4, the International Utilities were updated to take advantage of these new characters. For example, the upper case “E” with a grave accent first appeared in the extended Macintosh character set. With 6.0.4, the lower and upper case “E” with a grave accent were considered to be equal in primary ordering, and unequal in secondary ordering, which is correct. But RelString and EqualString, even today, still think in the old Macintosh character set, so they think that lower and upper case “E” with a grave accent have nothing to do with each other, and that’s not right.
Because the RelString and EqualString algorithms are more crude than the string comparison routines in the International Utilities, RelString and EqualString should win races with the International Utilities string comparison routines hands down. The File Manager uses them partly for this reason, and partly because RelString and EqualString don’t need access to the 'itl2' resource, which is usually pretty big. Normally, File Manager sorting isn’t critical anyway because it’s either irrelevant, or it can easily be cleaned up by using the International Utilities string comparison routines. The Standard File package, for example, uses the International Utilities string comparison routines to order file and folder names in its list so that the list is ordered correctly regardless of the system it’s running on.
X-Ref:
Inside Macintosh Volume VI, page 14-82, “The 'itlm' Resource”
Macintosh PRAM’s MachineLocation dlsDelta field
Written: 1/25/91
Last reviewed: 8/1/92
How is the dlsDelta field in PRAM’s time zone MachineLocation record used and set?
___
Currently, the dlsDelta field is not being used by Macintosh system software, nor is its meaning defined. There are plans to use it in the future, so it’s important that you preserve its current value if you ever use WriteLocation to set the value of gmtDelta. See the description of the WriteLocation routine in “WorldWide Development: Guide to System Software,” available on the latest developer CD and from APDA (#M7047/A), for details on getting and setting gmtDelta while leaving dlsDelta intact. In short, the code looks like this:
VAR
myLocation: Location;
myGMTDelta: LongInt;
tempSignedByte: SignedByte;
:
tempSignedByte := myLocation.dlsDelta;
myLocation.gmtDelta := myGMTDelta;
myLocation.dlsDelta := tempSignedByte;
Why 1904 is Macintosh Time base
Written: 9/6/91
Last reviewed: 8/1/92
The global variable Time contains the number of seconds since midnight, Jan. 1, 1904. Why was the year 1904 chosen ?
___
The ability to go back in time is one consideration. You would not want to start the clock from, say, 1984. You also want to go ahead in time a good amount, of course. So, the clock start date needs to put our current date somewhere in the middle of the clock’s range.
So what is the clock’s range? Since the clock chip has a four byte counter which is incremented each second, they had 4,294,967,295 seconds to work with, or approximately 136 years. This would make the Macintosh clock run out in 1904+136 = 2040. The maximum value, $FFFFFFFF, corresponds to 6:28:15 a.m., February 6, 2040.
Given the possible range of years/leap years/nonleap years (every fourth year, but not if at the end of a century, except at the end of every fourth century, which is a leap year) and the date when the clock will run out (2040) - the “leap year code” in the Macintosh only has to deal with the rule “every fourth year is a leap year” because none of the possible Macintosh dates violate that rule! Remember, 2000 is evenly divisible by 400, so it IS a leap year. 1900 is not. If they started at 1900, they would have to use a different algorithm that accounts for “non-leap year” leap years. Some other clocks start on 1901.
Why did they start on 12:00:00, January 1, 1904? Well, it probably has to do with 1904 being the first leap year after a “non-leap year” leap year (1900). So, the year was chosen for mechanical (4 byte limit on number of seconds) and pragmatic (you only want to use one algorithm to figure out the date et al) considerations.
So, back to the future...
X-Ref:
Chapter 4, “Worldwide Guide to System Software”
System 7 and 'itl1' resources
Written: 9/16/91
Last reviewed: 8/1/92
System 7 doesn’t recognize some of my 'itl1' resource changes, such as date abbreviation length, that are recognized by System 6.
___
The field that you refer to is not doing what you want because System 7 introduced an expanded 'itl1' resource, with several new fields, including arrays that contain the proper abbreviations of all the months and days. If you look in Inside Macintosh Volume VI on pages 14-87 thru 14-89 you’ll find a description of this new resource as well as the rez definition of it. Note the two new arrays, abbrevDays and abbrevMonths. If you were to modify these additional fields, you’d see the date in the finder windows change. (In fact, the abbrev length field does not seem to be used if these new fields are present.)
'itl0' resource time1Suff…time8Suff field interpretation
Written: 11/4/91
Last reviewed: 8/1/92
How are the 'itl0' resource time1Suff, time2Suff, … to be interpreted? On the German system, these bytes seem to contain “ Uhr Uhr.” The correct 24-hour time suffix should be a single “ Uhr.” How do we know how many bytes of this 8-character entity are significant? Similar question for the mornStr and eveStr: are all 4 characters of each of these significant?
___
The time1Suff…time8Suff fields in the 'itl0' resource of all localized systems divide those fields into two sections. The first four bytes (time1Suff through time4Suff) are used from 12:00 midnight through one second before noon, and the last four bytes (time5Suff through time8Suff) are used from 12:00 noon through one second before midnight. This is to take into account any system that has hours from 00:00:00 through 23:59:59, but has different time trailers for the morning and evening hours. I don’t know of any that work this way offhand, though. The German standard is just to append “Uhr” onto the time, morning or evening, and it’s separated from the time by one space. Any unused bytes just contain zero. For example, if the German time suffix was “Uh”, then the time suffix fields would contain a space, “U”, “h”, zero, space, “U”, “h”, and zero. If there’s no time suffix, then all eight bytes are zero.
The morning string and evening strings are done in a similar way. Each one holds a maximum of four bytes, and any unused bytes are filled with zeros.
By the way, you’ll find that a lot of time suffixes are filled in with something even though the flags say that time suffixes aren’t used. This is just localization garbage, which probably will be cleaned up someday.
International Canceling
Text M.TE.InternationalCancel
Written by: John Harvey February 1990
This Technical Note describes potential problems canceling operations with the Command-period key sequence and international keyboards.
Where Did That Key Go?
Canceling an operation, from printing to compiling, has always been done with the key sequence Command-period. The problem with this is that on some international systems, one needs to hold the Shift key down to produce a period. Many keyboard mappings, including that of the U.S., ignore the Shift key when the Command key is down. In other words, on a system where a period (.) is a shifted character (e.g., Italian) pressing Command-Shift-KeyThatMakesAPeriod does not generate the ASCII code for a period. Instead, the keyboard mapping software generates the ASCII code for the unshifted character. If an application is looking for Command-period to cancel some time intensive operation, and an international user types the shifted key sequence that normally produces a period along with the Command key, the application is going to miss that request unless it takes special precautions.
A Bit Confusing (to me at least)
The solution to this potential international disaster is to strip the Command key out of the modifiers, and then run the key code back through the keyboard mapping software. The trap _KeyTrans makes this procedure very easy. _KeyTrans takes as parameters a pointer to a 'KCHR' resource (see M.TB.KeyMapping), a word which contains the keycode and the modifier bits, and a word which serves as a state variable.
One note on the result returned by _KeyTrans. Inside Macintosh, Volume V-195, The Toolbox Event Manager, states, “ASCII 1 is the ASCII value of the first character generated by the key code parameter.” This statement is followed by an illustration (Figure 7 on page V-195) which shows ASCII 1 as the low byte of the high word in the long word result. Although this statement and the accompanying illustration are correct, they have mislead a number of people (me for one).
It is dangerous to expect the character code in one particular word of the long word result. In fact, the architecture of the _KeyTrans trap does not specify which word contains the character code in which you might be interested. This is because the _KeyTrans trap’s primary purpose is to create a package that can be used to build a key-down event, and the Toolbox Event Manager just doesn’t care about particular keys. In fact, it is possible to get a result from _KeyTrans that contains character codes in both words. This is how dead keys are handled.
But how does one handle a particular character, specifically a period? The strategy adopted in the sample function in this Note is to check both words of the result. If a period exists in either word and the Command key is down, it is counted as a Command-period key sequence.
Now that everything is straight about parameters and results, it’s time to look at some sample code. The code fragment which follows ensures that you get that period regardless of the state of the modifier keys.
MPW Pascal
CONST
kMaskModifier = $FE00; {need to strip command key from Modifiers}
kMaskVirtualKey = $0000FF00; {get virtual key from event message}
kMaskASCII1 = $00FF0000;
kMaskASCII2= $000000FF; {get key from KeyTrans return}
kKeyUpMask = $0080;
kPeriod = ORD('.');
TYPE
EventPtr = ^EventRecord;
FUNCTION CmdPeriod(theEvent: EventPtr): Boolean;
VAR
keyCode : Integer;
virtualKey,
keyInfo,
lowChar,
highChar,
state,
keyCId : Longint;
hKCHR : Handle;
BEGIN
CmdPeriod := FALSE;
IF ( theEvent^.what = keyDown ) | ( theEvent^.what = autoKey ) THEN BEGIN
{see if the command key is down. If it is, get the ASCII }
IF BAND(theEvent^.modifiers,cmdKey) <> 0 THEN BEGIN
virtualKey := BAND(theEvent^.message,kMaskVirtualKey) DIV 256;
{strip the virtual key by ANDing the modifiers with our mask}
/* Don't bother locking since KeyTrans will never move memory */
keyInfo = KeyTrans(*hKCHR, keyCode, &state);
ReleaseResource( hKCHR );
}
else
keyInfo = (*theEvent).message;
lowChar = keyInfo & kMaskASCII2;
highChar = (keyInfo & kMaskASCII1) >> 16;
if (lowChar == kPeriod || highChar == kPeriod)
fTimeToQuit = true;
} // end the command key is down
} // end key down event
return( fTimeToQuit );
}
What About That Resource
The astute observer may have noticed that the code example requires that you read a resource. Although this certainly isn’t that big of a deal, it is always nice when you can cut down on disk accesses. In System 7.0 a verb is added that can be used to get _GetEnvirons to return a pointer to the current 'KCHR'. The verb is defined and used as follows:
Pascal
CONST
smKCHRCache = 38;
KCHRPtr := GetEnvirons(smKCHRCache);
C
#define smKCHRCache 38
KCHRPtr = GetEnvirons(smKCHRCache);
Unfortunately, in system software prior to 7.0, you must use _GetResource as demonstrated above to obtain the current 'KCHR' resource. However, since _GetEnvirons always returns zero when passed a verb it does not recognize, you can build System 7.0 compatibility into your application without having to check which system software is running. To do this, you could modify the routines as follows:
Pascal
CONST {define our own constant until System 7.0 headers ship. At that point, if you
have not shipped, you can put in the real constant}
NewVerb_smKeyCache = 38;
VAR
KCHRPtr : Ptr;
KCHRPtr := Ptr(GetEnvirons(NewVerb_smKeyCache ));
hKCHR := NIL; {set to NIL before starting}
IF KCHRPtr = NIL THEN BEGIN {we didn't get the ptr from GetEnvirons}
• Inside Macintosh, Volume V, The Toolbox Event Manager
• M.TB.KeyMapping
Changes in International Utilities and Resources
Text M.TE.IUChanges
Revised by: March 1988
Written by: Priscilla Oppenheimer July 1987
The International Utilities package and the international resources have been changed with System file 4.1 to take advantage of the Script Manager.
INTL vs. itl
In the past, there were two INTL resources in the System file, INTL 0 and INTL 1, which contained international formatting options. Starting with System 4.1, itl0 and itl1 replace INTL 0 and INTL 1. (INTL 0 and INTL 1 are still included with the System file so that applications that do a GetResource for them will still find them. Only these erroneous applications that use GetResource will access these resources now; the System will no longer look at them.) There can now be a set of international resources (itls) for each script that is installed. That is, where once there was one resource type (INTL) with IDs 0 and 1 there are now many different resource types (itl0, itl1, itl2, itlb, itlc, KCHR) with distinct resource IDs for the various countries. The U.S. System file uses resource ID 0 for all itl resources.
If your existing application calls IUGetIntl to get the appropriate international resource, you will have no problems under System 4.1. If, however, you call GetResource on INTL 0 or INTL 1 and then modify them, and expect that the System will use the modified resource, you will no longer work correctly. If your application has been released in the past with a modified System file to include your own INTL 0 and/or INTL 1, you may want to release your application with a modified itl0 and/or itl1.
The International Sorting Routine
The international sorting routine is used to handle cases where letters are equal in primary ordering but different in secondary ordering (e.g., “ä” and “a”). The routine can also handle cases where one character sorts as if it were two, or two characters would sort as if they were one, or even character reversals.
Prior to System 4.1, the international sorting routine was stored starting with the localRtn field of INTL 1. As of System 4.1, this routine is now stored in itl2. An INTL 2 resource is also included with the international resources, just for consistency (the System never uses it). It is exactly the same as itl2.
Writing your own sorting routine can be dangerous if it is not done correctly. Before attempting to do this, we would highly recommend you check with Apple to determine if we are already doing one for the language of interest. We plan to do many international versions of System file 4.1, and most developers’ needs will be met by these. A new policy at Apple will now make it possible to license foreign versions of the System file from Software Licensing. Contact Software Licensing at (408) 973-4667 for more information about this.
Error in APDA draft of Inside Macintosh Volume V
There is an error in the APDA draft of the International Utilities Package chapter of Inside Macintosh Volume V. It says that there is a flag in the Script Manager globals that overrides the current font and always uses the INTL 0 and INTL 1 resources. This is not true. INTL 0 and 1 have been replaced by itl0 and itl1, and are not used except by applications that explicitly get them by doing a GetResource. There is a relevant Script Manager flag called IntlForce that is correctly but incompletely explained in the Script Manager chapter. When IntlForce is false, the resources used by the International Utilities are determined by the current script. The script that is in use is determined by which font is in use for the port in use. For example, if you switch to the Kyoto font, then you will be using the Japanese Script Interface System (KanjiTalk). If you do this with IntlForce set to false, then you will use the resources that are associated with the Japanese Script Interface System.
When IntlForce is true, the International Utilities always use the resources that are associated with the system script; this is usually Roman. IntlForce is true by default. Actually, the Script Manager initialization routine reads the itlc resource to determine what the default is, and Apple plans to release the various international System files with this field set to true in the itlc resource. Applications that want to change the value of IntlForce can use the Script Manager call SetEnvirons with the smIntlForce verb. There is a Script Manager call, IntlScript, to find out the current value.
Bug in System 4.1 version of itl1
There is a bug in the itl1 resource in System 4.1. The itl1 resource contains arrays of day and month names, as did the INTL 1 resource. Their formats are:
days ARRAY [1..7] of STRING[15]
months ARRAY[1..12] OF STRING[15]
Every day and month is supposed to be coded as a Pascal string with a maximum of 15 characters, and the actual length in the first byte of the string. In System 4.0 and System 4.1, the contents of each string is always a Pascal string of length 15, with the unused characters set to nulls. In other words, the length byte is set to hex 0F. This will be fixed in a future release of the System file. If it is currently causing your application problems, you can change the lengths with ResEdit, or change them at run time, or use your own itl1 resource and release your application with an installer script. The recommended approach is to wait for a fixed version of the System file from Apple.
Further Reference:
• The International Utilities
• The Script Manager
Keyboard Resource Q&As
Text M.TX.KeybdRes.Q&As
Revised by: Developer Support Center October 1992
Written by: Developer Support Center October 1990
This Technical Note contains a collection of Q&As relating to a specific topic—questions you’ve sent the Developer Support Center (DSC) along with answers from the DSC engineers. While DSC engineers have checked the Q&A content for accuracy, the Q&A Technical Notes don’t have the editing and organization of other Technical Notes. The Q&A function is to get new technical information and updates to you quickly, saving the polish for when the information migrates into reference manuals.
Q&As are now included with Technical Notes to make access to technical updates easier for you. If you have comments or suggestions about Q&A content or distribution, please let us know by sending an AppleLink to DEVFEEDBACK. Apple Partners may send technical questions about Q&A content to DEVSUPPORT for resolution.
New Q&As and Q&As revised this month are marked with a bar in the side margin.
ResEdit and Macintosh Portable 'KCAP' resources
Written: 6/17/91
Last reviewed: 1/27/92
I am trying to use the 'KCAP' resource to draw the Macintosh Portable keyboard layout in our application. I used the ResEdit to check 'KCAP' in both System 7 and the Key Layout file, but the Portable keyboard type is not there.
___
The resource numbers 6 and 7 of 'KCAP' are contained in the ROM of the Portable and some other Macintosh models. Being located in ROM, the resources are not directly viewable with ResEdit. They do, however, exist in the resource chain, so a RGetResource for 'KCAP' number 6 should load and return a pointer to this resource. ROM resources and the resource chain are discussed in the Resource Manager chapters of Inside Macintosh Volumes IV and V.
Using Macintosh KCAP resource to draw a keyboard
Written: 1/10/92
Last reviewed: 4/7/92
How can I use the KCAP resource to draw the keyboard?
___
KCAP resources describe the key layout of Macintosh keyboards. They are intended for use by the Key Caps desk accessory, but applications can also take advantage of KCAPs for information about key arrangements. The program kcapApp demonstrates use of the KCAP resource and is available in the Snippets collection.
This is the format of the KCAP resource:
rect, boundary for the keyboard (8 bytes)
rect, appropriate for an editable line of text (8 bytes)
integer, number of key shapes to follow (2 bytes)
for each key shape:
integer, number of points defining this key shape - 1 (2 bytes)
for each point:
point, opposite corner of a rect (2 bytes)
number of keys of this shape - 1 (2 bytes)
for each key:
byte, modifier mask (1 byte)
byte, OR/AND setting for modifier mask (1 bit) plus
virtual keycode for this key (7 bits)
integer, vertical offset from previous key (2 bytes)
integer, horizontal offset from previous key (2 bytes)
The keyboard boundary rect may be offset from the origin. It can be realigned with
Each key shape consists of one or more rectangles. The rectangles are defined by a series of points, with one point specifying each rectangle. The first point is the opposite corner of a rectangle anchored at the starting pen location for the key; the next point is the opposite corner of a rectangle from the last point; and so on. The key shape is the union of the rects defined by the points.
Note that a rectangle’s point may be above or to the left of the previous point. To QuickDraw, this would define an empty rectangle, so the rectangle’s horizontal and/or vertical coordinates may need to be swapped before FrameRect is called to add a rect to the key’s region.
The pen is moved to the top left of the keyboard boundary rect before drawing each group of keys of a given shape. The pen location for each key is given as a horizontal and vertical offset from the pen location for the previous key. The pen location for the first key of each shape is an offset from the top left corner of the keyboard boundary rectangle. The pen does not change location when a key is drawn.
Use KeyTrans to determine the character to be drawn on the key. The KCAP resource provides a 7-bit virtual keycode, plus a mask for the modifiers to be passed to KeyTrans. If the most significant bit of the keycode byte is set, AND the desired modifiers with the modifier mask. If the bit is clear, OR the modifiers with the mask.
The high bit of the virtual keycode byte indicates to KeyTrans the type of the keystroke; before calling KeyTrans, clear the bit for a keydown, or set it for a keyup. The bit should be clear if you’re drawing a keyboard. KeyTrans sets the state appropriately for dead keys only when called for keydowns.
The global KbdType ($21E), a byte, contains the KCAP resource number for the last keyboard used. Under System 6, KCAP resources are kept in the file “Key Layout” in the System folder. Starting with System 7, KCAP resources are in the System file. Alternatively, a machine’s KCAP may be stored in ROM, where it’s available with the GetResource call but cannot be viewed with ResEdit.
For more information on KeyTrans and KCHRs, see Chapter 10 of Inside Macintosh Volume V, pages 14-23 and 14-96 of Inside Macintosh Volume VI, and the Macintosh Technical Note “Key Mapping.” KCAP resources are discussed on pages 14-95, 14-100 and 14-101 of Inside Macintosh Volume VI.
Macintosh Option key: Techniques for ignoring
Written: 10/16/91
Last reviewed: 2/28/92
I would like to use the Macintosh Option key as the Control key for keyboards that lack a Control key, such as for Macintosh Plus keyboards. How can I find the ASCII value that would have been returned if the Option key weren’t pressed, in a way that would be compatible with other keyboards?
___
There are a couple of clean ways to ignore the Option key. One is to “reprocess” the keyboard event. The fourth byte of the event message is the ASCII code, but the third byte is the virtual key code. The system calls the trap KeyTrans to map the virtual key code to ASCII according to a 'KCHR' resource. You can do the same, and since the high byte of the modifiers are part of the input to KeyTrans, you can strip out the Option key, call KeyTrans on the third byte of the event message, and get back the “true” ASCII keypress. KeyTrans and 'KCHR' resources are documented in Chapter 10 of Inside Macintosh Volume V, Chapter 14 of Inside Macintosh Volume VI (pages 14-23 and 14-96), and the Macintosh Technical Note “Key Mapping.” In Pascal, these steps would look something like:
keycode := BAND(event.message, keyCodeMask); { get virtual code }
The resource ID of the current KCHR is available as GetScript(GetEnvirons(smKeyScript), smScriptKeys). Alternatively, a pointer to the KCHR data is available under System 7 as GetEnvirons(smKCHRCache), as discussed in the Tech Note “International Canceling.”
This method may work for you, but there is a possible problem: dead keys. Since dead keys are processed before your application gets the event, your application will not see (for example) the first Option-e typed. However, the dead keys are specified in the 'KCHR' resource, so you can create a KCHR (ResEdit 2.1.1 includes a template) to omit dead keys (and, if you choose, option characters) and include it with your application. Call SetScript to get the system to use your 'KCHR' (see the Tech Note “Key Mapping,” IM V-313, and IM VI 14-40).
Another problem is that System 7 ignores a 'KCHR' in the application’s resources, so an application’s 'KCHR' has to be installed in the system. You can install the 'KCHR' with an installer program, or provide a keyboard file users can drag to the System file. (To create a keyboard file, use ResEdit to put the 'KCHR' in the System file, and then drag it out with the System 7 Finder.)
Script Manager’s Pixel2Char Routine
Text M.TE.Pixel2Char
Revised by: Mark B. Johnson & Dave McGary August 1989
Written by: Sue Bartalo June 1989
This Technical Note discusses the Pixel2Char routine provided by the Script Manager.
Changes since June 1989: Clarified information, corrected minor errors, and replaced the illustration.
The leftSide flag in the Pixel2Char routine was inappropriately named, and it should now be called the leadingEdge flag. The reason for this change is that the value Pixel2Char returns indicates whether a mouse-down occurred on the leading edge of a character, which is not always the left side. (In Arabic or Hebrew, both of which are right-to-left scripts, the mouse-down occurs on the right side of the character.)
With this change, the interfaces also change. Following are both the old and new definitions in Pascal and C respectively:
Old Definition
FUNCTION Pixel2Char(textBuf: Ptr;textLen: INTEGER;slop: INTEGER;pixelWidth: INTEGER;
VAR leftSide: BOOLEAN): INTEGER;
pascal short Pixel2Char(Ptr textBuf,short textLen,short slop,short pixelWidth,
Boolean *leftSide)
New Definition
FUNCTION Pixel2Char(textBuf: Ptr;textLen: INTEGER;slop: INTEGER;pixelWidth: INTEGER;
VAR leadingEdge: BOOLEAN): INTEGER;
pascal short Pixel2Char(Ptr textBuf,short textLen,short slop,short pixelWidth,
Boolean *leadingEdge)
The value of the leadingEdge flag is True if a mouse-down occurs on the leading edge of the character in its direction (e.g., the left side for a left-to-right script (Roman) and the right side for a right-to-left one (Arabic or Hebrew)). Figure 1 illustrates these differences.
This Note describes the way script systems should work; however, in some systems, the values of leadingEdge and character offset are undefined when the pixelWidth is outside the boundaries of the text.
You define the start of a right-to-left line to be on the right and the end to be on the left; therefore, it follows that the start of a left-to-right line is on the left, while the end is on the right. The values at the start of a line should be False for leadingEdge and zero for character offset. The values at the end are True for leadingEdge and the character offset is the total byte count of that line. You should check for these out-of-bounds conditions explicitly and perform the appropriate actions. This change will appear in the next version of the Script Manager documentation.
Figure 1–Pixel2Char leadingEdge Flag
Accessing the Script Manager Print Action Routine
Text M.TE.PrintAction
Revised by: March 1988
Written by: Mark Davis November 1987
This technical note describes how Print Drivers can access the Script Manager Print Action routine to print unconventional text, such as Japanese or Arabic.
General Notes
Scripts such as Japanese or Arabic modify the normal QuickDraw text handling in order to represent text properly. On the screen, this is done by trapping StdText and StdTxtMeasure, and transforming the text before printing. For example, for Hebrew or Arabic the text might be reversed, since text normally goes from right to left in those scripts.
Print drivers require slightly different handling, for two reasons:
1. A print driver might not call the standard QuickDraw procedures. For example, the LaserWriter writes directly in PostScript instead.
2. A print driver might need to format the text, for accurate line-layout. In this case, the text needs to be transformed before the driver performs line-layout. If the driver is spooling the text, and will replay the text a second time, the text cannot be transformed a second time, since that would ruin the appearance.
For example, the ImageWriter driver calls QuickDraw procedures twice, once to spool and once to unwind the spooling. The text must be transformed when spooling, so that line layout can be done, but when unwinding, the transformation must be turned off completely.
Note that some drivers, such as the LaserWriter, use QuickDraw re-entrantly: the application program calls a QuickDraw routine, which is directed to the driver’s grafProcs, which in turn call QuickDraw internally to put up status messages on the screen. The Print Action procedure handles the text properly so that the text transformations are enabled during the re-entrant calls, so that the status messages will be properly formatted.
When To Call the Print Action Routine
The Script Manager Print Action routine allows the print driver to be independent of the particular scripts being used. The printing driver should call this routine whenever it changes the grafProcs in the printing grafPort. The Print Action routine will then substitute grafProcs of its own in the grafProcs record, saving the original routine addresses.
The Print Action routine will actually call a Print Action routine for each script system that is currently installed. Each of the script Print Action routines will do the appropriate tasks for its system.
Calling the Print Action Routine
To call the Print Action routine, the driver should use the following code:
intlGlobals equ $ba0 ; international globals
printActionOff equ $16 ; offset to PrintAction proc ptr
; get procedure pointer to call
tst.w Rom85 ; on a Macintosh + or better?
blt.s @PrintActionDone ; no, skip
move.l intlGlobals,d2 ; get international globals
ble.s @PrintActionDone ; not there, skip
move.l d2,a0 ; in address register
move.l printActionOff(a0),d2 ; get print action address
beq.s @PrintActionDone ; not there, skip
move.l d2,a0 ; in address register
; set up arguments to call
move.l <myPort>,d0 ; pass the port
move.w <myVerb>,d1 ; pass the verb
jsr (a0) ; call the procedure
@PrintActionDone
Print Action Routine Verbs
There are currently three verbs to pass to the Print Action routine.
paUnwindText equ –1
paSpoolText equ 1
paNoQuickDraw equ 3
Use the paUnwind verb to ensure that the text is not transformed before your StdText procedure receives the text. This verb is used when playing back stored text that has already been transformed.
The other two verbs (paNoQuickDraw and paSpoolText) are used to ensure that the text is transformed before your StdText procedure receives the text. The paSpoolText verb is used when your driver will use QuickDraw to image the text in the printing grafPort. The paNoQuickDraw verb is used when the text is not drawn into the printing port by going through QuickDraw (e.g. the LaserWriter). In that case some languages (e.g. Japanese) which use an extended font structure may need to recast the text calls as CopyBits calls.
As mentioned above, some applications may call QuickDraw from within the driver, as when a status window is updated. During any StdTxtMeasure calls in the driver during the application’s call to StdText, the port is checked against the printer port. If they match, then the text is not transformed. Otherwise, the text is transformed.
The solutions adopted by the Print Action routine assume that the print driver does not measure or draw text except within calls to StdTxtMeasure or StdText. If your driver does text buffering (as for line layout), make sure that any measurements are performed within these two calls. For example, you might buffer both the text and its screen width as measured by QuickDraw.
Further Reference:
• The Script Manager
Safe cdevs
Text M.TE.SafeCDEV
Written by: John Harvey August 1989
This Technical Note describes a potential problem with Control Panel devices (cdevs) that contain EditText fields and presents a way to avoid it.
The Control Panel chapter in Inside Macintosh, Volume 5 describes, in detail, how run-time errors are handled by the Control Panel and a cdev. There is, however, a potential problem with cdevs that contain EditText items that this chapter does not cover.
When a cdev is called by the Control Panel, the cdev’s 'DITL' resource is concatenated to the Control Panel’s 'DITL'. The Control Panel then lets the Dialog Manager update the window. If the cdev contains an item of type EditText, the Dialog Manager allocates and activates a TEHandle to be used for displaying and editing text. All of this action happens before the cdev gets the initDev message from the Control Panel.
As detailed in The Control Panel chapter, if an error occurs from which a cdev cannot recover, the cdev should dispose of any private memory and return the appropriate error code or a NIL value to the Control Panel. The Control Panel then grays out the cdev’s area, displays the appropriate error dialog, and then deletes the items that were added to its 'DITL'.
All of this is fine, except that the TEHandle does not get deallocated. The EditText items get thrown away, including the strings in the item list that the Dialog Manager would use to store text entered into the EditText field, but the TEHandle stays there and stays active. Figure 1 illustrates what this would look like.
Figure 1–Erroneous Insertion Point
So the Dialog Manager, knowing that it allocated a TEHandle for an item that was visible, goes merrily on its way flashing the insertion point. The problem is not simply one of appearance. If a user hits a key, the Dialog Manager tries to process the key-down event just as if the EditText item was still available, and this series of events causes a rather nasty crash.
Fortunately, the solution for this problem is a very simple one. If an EditText item is hidden with a _HideDItem call, the Dialog Manager does not consider it active and will not try to process key-down events for it. So if your cdev contains EditText items, part of your error handling should be to first hide the EditText items with a call to _HideDItem before returning an error code or a NIL as the cdev’s function result.
Further Reference:
• Inside Macintosh, Volume I, The Dialog Manager
• Inside Macintosh, Volume IV, The Dialog Manager
• Inside Macintosh, Volume V, The Control Panel
Script Manager Q&As
Text M.TX.ScriptMgr.Q&As
Revised by: Developer Support Center November 1992
Written by: Developer Support Center October 1990
This Technical Note contains a collection of Q&As relating to a specific topic—questions you’ve sent the Developer Support Center (DSC) along with answers from the DSC engineers. While DSC engineers have checked the Q&A content for accuracy, the Q&A Technical Notes don’t have the editing and organization of other Technical Notes. The Q&A function is to get new technical information and updates to you quickly, saving the polish for when the information migrates into reference manuals.
Q&As are now included with Technical Notes to make access to technical updates easier for you. If you have comments or suggestions about Q&A content or distribution, please let us know by sending an AppleLink to DEVFEEDBACK. Apple Partners may send technical questions about Q&A content to DEVSUPPORT for resolution.
New Q&As and Q&As revised this month are marked with a bar in the side margin.
Using FormatXToStr and FormatStrToX with Pascal switches
Written: 12/10/90
Last reviewed: 8/1/92
Why do the FormatXToStr and FormatStrToX Script Manager routines stop working when I use the Pascal -MC68881 switch?
___
Regular SANE extended numbers are 10 bytes long while MC68881 extended numbers are 12 bytes long, and the extra two bytes are right in the middle of every 68881 extended number. Appendix G “The SANE Library” in the Macintosh Programmer’s Workshop (MPW) Object Pascal version 3.1 manual goes into detail about this. The FormatX2Str and FormatStr2X parse the extended number you pass them directly, and they can only parse 10-byte extended numbers. Fortunately, you can still use the -mc68881 option with these routines as long as you convert any extended numbers to 80-bit extended numbers before passing them to FormatX2Str and FormatStr2X. The SANE.p unit has routines to do this called X96toX80 and X80toX96 (incorrectly documented as X96to80 and X80to96 in the MPW Object Pascal manual). Because the extended80 and extended96 types aren’t equivalent to the extended type as far as Object Pascal is concerned, you have to redeclare FormatX2Str and FormatStr2X to take these types. You can do this as follows:
FUNCTION FormatX2Str80 (x: extended80;
myCanonical: NumFormatString;
partsTable: NumberParts;
VAR outString: Str255): FormatStatus;
INLINE $2F3C,$8210,$FFE8,$A8B5;
FUNCTION FormatStr2X80 (source: Str255;
myCanonical: NumFormatString;
partsTable: NumberParts;
VAR x: extended80): FormatStatus;
INLINE $2F3C,$8210,$FFE6,$A8B5;
Call these routines instead of the originals. To call FormatX2Str80, all you have to do is this:
VAR
x: extended80; {96-bit extended number}
myCanonical: NumFormatString;
partsTable: NumberParts;
outString: Str255
result := FormatX2Str80 (X96toX80 (x), myCanonical, partsTable, outString);
Calling FormatStr2X80 is just slightly more complicated because the extended number is passed by reference:
VAR
x: extended; {96-bit extended number}
x80: extended80; {80-bit extended number}
source: Str255;
myCanonical: NumFormatString;
partsTable: NumberParts;
x80 := X96toX80 (x);
result := FormatStr2X80 (theString, realCanon, PartsTable, x80);
x := X80toX96 (x80);
You should find that these calls now work properly with the -mc68881 option
set. This of course means that you’ll need two versions of the source code; one with the calls to convert between 96-bit and 80-bit extended numbers for use with the -mc68881 option and another one which just uses plain old 80-bit extended numbers for use when the -mc68881 option is turned off.
X-Ref:
Inside Macintosh Volume VI, page 14-49.
String2Date and Date2Secs conversion surprises
Written: 9/17/91
Last reviewed: 8/1/92
String2Date and Date2Secs treat all dates with the year 04 to 10 as 2004 to 2010 instead of 1904 to 1910.
___
This is correct; the Script Manager treats two-digit years less than or equal to 10 as 20xx dates if the current year is between 1990 and 1999, inclusive. Basically, it just assumes that you’re talking about 1-20 years in the future, rather than 80-100 years in the past. The same is true of two-digit 9x dates, when the current year is less than or equal to xx10. Thus, in 2003, the date returned when 3/7/94 is converted will be 1994, not 2094. This is all documented in “Worldwide Development: Guide to System Software,” available from APDA.
FormatX2Str strings
Written: 11/6/91
Last reviewed: 8/1/92
Using the Script Manager to convert numbers to strings and vice versa, in any language, what’s the best way to create the string to pass to FormatX2Str? Will strings using the characters: “#” or “0” or “.” or “,” work no matter what script is currently running, and if not, what can I do?
___
The number format string and canonical number format string mechanisms that you use with FormatX2Str and its kin is a strange design, for exactly the reason that you asked about. The number format string (the one with the characters such as “#” and “0”) does not necessarily work right regardless of the current script. In fact, it doesn’t even necessarily work right between localized versions within one script system. The canonical number format string does work between localized systems and between script systems. The strange thing is there’s an easy way to store number format strings (usually in a 'STR ' resource), but no obvious way to store canonical number format strings. Here’s what you can do when converting between numbers and strings:
When you convert a number format string to a canonical number format string with Str2Format on a U.S. system, it converts it from something like “###.###” to a canonical number format string that looks something like, “three digits, a decimal point, and three digits.” On a German system, that same number format string would be converted to “three digits, a thousands separator, and three digits.”
What you can do to get around this is to save the canonical number format string in a resource instead of the number format string. The canonical string stores things in a language- and script-independent way. Create this resource by writing a trivial utility program that takes a number format string and calls Str2Format to convert it into a canonical number format string, and then copy this into a handle and save it as a resource of a custom type, like 'NUMF'. In your real program, load the 'NUMF' resource, lock it, and then pass the dereferenced handle to FormatX2Str and FormatStr2X.
You can see this done in the ProcDoggie Process Manager sample from the 7.0 Golden Master CD. Take a look at the SetUpProcessInfoItems procedure in UProcessGuts.inc1.p file. You’ll see that the 'NUMF' resource is loaded, locked, and then passed to FormatX2Str. The result is displayed in the Process Information window.
If your program is localized by nonprogrammers, then you might want to provide the utility that converts a number format string to a canonical number format string resource just in case they have to change the entire format of the string. Then they can install the new 'NUMF' (or whatever you choose) resource as part of the localization process.
Code for truncating a multi-byte character string
Written: 1/24/92
Last reviewed: 8/1/92
I create a Macintosh file name from another file name. Since I am adding information to the name, I must make sure that it is within the 31 chars maximum allowed by the operating system. What I need is the equivalent of the TruncText command, except instead of dealing with pixel width, I want the width to be number of characters (31). I can trunc myself, but I’d rather do a proper “smTruncMiddle” and have it nicely internationalized.
___
If you’re going to be adding a set number of bytes to the end of a existing string and you don’t want the localized ellipsis (from the 'itl4' resource) between the truncated string and your bytes, then you can use this routine:
{ This procedure truncates a Pascal string to be of length maxLength or }
{ shorter. It uses the Script Manager charByte function to make sure }
{ the string is not broken in the middle of a multi-byte character. }
VAR
charType: Integer;
BEGIN
IF Length(theString) > maxLength THEN
BEGIN
charType := CharByte(@theString[1], maxLength);
WHILE ((charType < 0) OR (charType > 1)) AND (maxLength <> 0) DO
BEGIN
maxLength := maxLength - 1;
charType := CharByte(@theString[1], maxLength);
END;
theString[0] := chr(maxLength);
END;
END;
If you want the localized ellipsis (from the 'itl4' resource) between the truncated string and your bytes, or you want the localized ellipsis in the middle of the combined strings truncated to a specific length, then you can use this routine:
FUNCTION TruncPString (maxLength: Integer; VAR theString: Str255;
truncWhere: TruncCode): Integer;
{ This function truncates a Pascal String to be of length maxLength or }
{ shorter. It uses the Script Manager TruncString function which adds }
{ the correct tokenEllipsis to the middle or end of the string. See }
{ Inside Macintosh Volume VI, pages 14-59 and14-60 for more info. }
VAR
found: Boolean;
first, midPoint, last: Integer;
tempString: Str255;
whatHappened: Integer;
BEGIN
found := FALSE;
first := 0;
last := TextWidth(@theString[1], 0, Length(theString));
IF Length(theString) > maxLength THEN
BEGIN
WHILE (first <= last) AND NOT found DO
BEGIN
tempString := theString; { tempString gets destroyed every }
TruncPString := whatHappened; { will always be smTruncated }
{ in this case }
END
ELSE
TruncPString := smNotTruncated; { the string wasn't too long }
END;
Character type and subtype values within the Kanji system
Written: 11/17/89
Last reviewed: 8/1/92
What are the values of character type and subtype with the Macintosh Kanji system?
___
For Roman, these are the values of character type:
Punctuation 0
ASCII 1
European 7
For KanjiTalk, the values are the same as Roman, with the addition of:
Katakana 2
Hiragana 3
Kanji 4
Greek 5
Russian (Cyrillic) 6
In Roman, the subtype field is interpreted as:
Normal punctuation 0
Numeric 1
Symbols 2
Blanks 3
The KanjiTalk subtype values are the same as Roman except if the character type is Kanji, in which case the subtype field takes these values:
JIS Level 1 0
JIS Level 2 1
JIS User Character 2
Finally, for KanjiTalk, the character direction field is replaced by the In-ROM field. It is 1 if the character is in the ROM card and 0 otherwise.
Script Manager NMeasureJust documentation fix
Written: 7/21/92
Last reviewed: 9/15/92
The Script Manager’s NMeasureJust call seems to work differently depending on our main script (Roman versus Hebrew, for example). Please take a look at the following code and tell me if I’m doing something wrong:
// Under Hebrew system NMeasureJust acts differently than described in
// Inside Macintosh Volume VI; first entry in charLocs array containes width
// of last character and last entry in charLocs array containes zero.
charLocs[charCount] = charLocs[0];
charLocs[0] = 0;
};
....
}
___
The truth is that Inside Macintosh Volume VI is incorrect, and NMeasureJust is working correctly, even though the results seem to defy any kind of sense. Here’s how NMeasureJust works:
NMeasureJust actually puts into the first entry of the charLocs array the pixel offset from the left end of the text to the leading edge of the first character, regardless of the active script system. For Roman text in a Roman script system, that’s easy: it’s always zero. For Hebrew text in a Hebrew script system, the leading edge of the first character is on the right edge of the text, so NMeasureJust puts the pixel distance between the left edge of the text to the right edge of the text——the same thing as the entire width of the text. Each successive entry in the charLocs array is smaller than the previous entry because we’re gradually moving to the left edge of the text as we move through each successive character. The trailing edge of the last character is at the left edge of the string, and so the last entry in the charLocs array is zero.
What if you pass in text that contains both Roman and Hebrew text? This text contains a direction boundary, and NMeasureJust can sense this. For this case, NMeasureJust puts into the charLocs array a series of decreasing values for the right-to-left characters, and a series of increasing values for the left-to-right characters.
You’re probably passing Roman text (ASCII codes less than 127) to NMeasureJust with the Hebrew script system active to get the results that you reported. This case includes two direction boundaries: one at the beginning that’s right-to-left and contains no characters, one that’s left-to-right and contains all your Roman characters, and finally one that’s right-to-left and contains no characters. The first entry in the charLocs array measures the first right-to-left direction run even though it contains no characters, and so it contains the position of the right edge of your text. The last entry in the charLocs array is zero because it measures the last right-to-left direction run, which again contains no characters. All the charLocs entries between the first and the last measure the positions of the left-to-right, Roman characters, and so you get a series of increasing values. This is just a special case of passing text that contains direction boundaries to NMeasureJust.
Interfacing a Macintosh application with Map CDEV data
Written: 8/17/92
Last reviewed: 10/11/92
How can I provide my users with a “hook” to access the geographical database in Apple’s “Map” Control Panel from my application?
___
There’s no supported way of accessing the geographical database contained in the “Map” Control Panel. Here are some hints, however (just to satisfy your curiosity):
The data are stored in a resource of type 'CTY#', ID=-4064, in the Map cdev. The resource format is a list of word aligned (variable length) city entries, preceded by an integer indicating the number of entries. Each entry has the format
[Integer] length in bytes of the entry
[Longint] latitude in Fract; north = +
[Longint] longitude in Fract; east = +
[Longint] GMT difference in seconds; east = +
[Longint] (reserved; set to 0)
[PascalString] name of the city.
Script Manager Variables
Text M.TE.ScriptVars
Written by: John Harvey & Peter Edberg June 1989
This Technical Note describes, in detail, the local and global script variables.
Introduction
The Script Manager maintains a number of global variables which can be read with the routine _GetEnvirons. These variables can be set by a corresponding routine, _SetEnvirons. In addition, each script interface system maintains variables of its own. These are referred to as local variables in Inside Macintosh, Volume V-293, The Script Manager, and are read by _GetScript and set by _SetScript.
Think of it like this: the Script Manager maintains an environment in which different script interfaces can run. The global variables are used to set up and maintain the environment (thus the names for the routines _GetEnvirons and _SetEnvirons), and the local variables control how the script itself works (so we have _GetScript and _SetScript).
Global Variables
When you call _GetEnvirons or _GetScript, you describe the variable you are interested in with a verb. A verb is simply an integer constant which the Script Manager uses to figure out which variable you want to read or set. The z in Inside Macintosh, V-313, gives incorrect names and descriptions for some of the _GetEnvirons and _SetEnvirons verbs. Table 1 provides correct descriptions.
Constant Value Meaning
smVersion 0 Script Manager version number
smMunged 2 Global modification count
smEnabled 4 Script count; 0 if Script Manager not
enabled
smBidirect 6 Bidirectional script flag
smFontForce 8 Force font flag
smIntlForce 10 Force international utilities flag
smForced 12 Current script forced to system script
smDefault 14 Current script defaulted to Roman
script
smPrint 16 Print action vector
smSysScript 18 Preferred system script
smLastScript 20 Last keyboard script
smKeyScript 22 Keyboard script
smSysRef 24 System folder volRefNum
smKeyCache 26 [Obsolete, do not use]
smKeySwap 28 Keyboard swapping resource handle
smGenFlags 30 General flags
smOverride 32 Script override flags
smCharPortion 34 Ch vs Sp Extra proportion, 4.12 fixed
Table 1–Verbs for _GetEnvirons and _SetEnvirons
The descriptions in the table are still a bit sketchy. The next section describes each variable in more detail and describes the size of each global.
Byte or word globals are mapped to the low-order byte or word of the LongInt returned by _GetEnvirons, with the high-order parts set to zero. Similarly, for these globals _SetEnvirons ignores all but the appropriate part (low-order byte or word) of its params value.
Verb Name Bytes Brief Description
smVersion 2 Script Manager version number
At boot time, the version global is initialized to the value SMgrVers. The high byte is the major version number and is defined in the MPW interface files. The low byte is updated when any changes are made to the Script Manager.
smMunged 2 Global modification count
The munged global is initialized to zero at boot time and incremented when:
• _KeyScript changes the key script and updates smKeyScript and smLastScript
• _SetEnvirons is used to change a Script Manager global
smEnabled 1 Script count; 0 if Script Manager not enabled
At boot time or switch-launch time, the enabled global is initialized to zero, then incremented for each script that is installed and enabled. Since the Roman script system should always be installed by the Script Manager, a value of zero indicates that the Script Manager is not enabled.
It should be noted that older versions of the Script Manager treated this as a Boolean. In other words, if there was more than one script installed, _GetEnvirons(smEnabled) would return 255 (when _GetEnvirons returns a Boolean value $FF represents true).
For this reason, when testing to see if more than one script is installed, it is best to test as follows:
scriptsinstalled := GetEnvirons(smEnabled);
IF scriptsinstalled > 1 THEN
{more than one script available, use Chartype, etc.}
smBidirect 1 Bidirectional script flag
The bidirectional global indicates that at least one bidirectional script is installed. It should be set to true ($FF) by the Arabic and Hebrew script systems. This is not presently done, but will be corrected in future versions of these systems.
smFontForce 1 Force font flag
smIntlForce 1 Force international utilities flag
smForced 1 Current script forced to system script
smDefault 1 Current script defaulted to Roman script
At boot time, FontForce and IntlForce are set from the 'itlc' resource, and Forced and Default are set to zero. These are all flags with the value zero for false and $FF for true. FontForce and IntlForce control the operation of the _FontScript, _Font2Script, and _IntlScript routines. Forced and Default report the actions of these routines.
Setting FontForce to true forces Roman fonts to be interpreted as belonging to the system script. This is for compatibility with applications that hard-code font numbers.
IntlForce determines the behavior of the _IUGetIntl call. When intlforce is set to true, _IUGetIntl will return a handle to the international resources (of type 'itlx' where x is 0-2) for the system script. When IntlForce is false, the _IUGetIntl will use the font of the current port to determine the appropriate resources to fetch. Thus date formats, sorting, etc. can reflect the current script.
smPrint 4 Print action vector
Print action routine vector; set up at boot time. See M.TE.PrintAction.
smSysScript 2 Preferred system script
smLastScript 2 Last keyboard script
smKeyScript 2 Keyboard script
At boot time and switch-launch time, SysScript and KeyScript are set from the SysScript field of the 'itlc' resource if that script is installed and enabled; otherwise, SysScript and KeyScript are set to Roman (without setting Default).
The KeyScript global is the current keyboard script, tested and updated by the _KeyScript routine. When _KeyScript changes KeyScript, it moves the old value to LastScript. _KeyScript can also swap the current key script with the last one, which it retrieves from LastScript. The KeyScript value is also used to get the proper keyboard script icon and to retrieve the proper 'KCHR'.
SysScript specifies the system script, and is used, for example, by _FontScript, _Font2Script, and _IntlScript.
KeyScript, LastScript, and SysScript always contain integers that correspond to a script number. Script numbers are documented in The Script Manager chapter of Inside Macintosh, Volume V-293.
smSysRef 2 System folder volRefNum
Set from the global BootDrive at boot time and switch-launch time. SysRef was originally a way of testing for vanilla launch versus switch launch; now the Enabled global is used for that purpose.
smKeyCache 2 [Obsolete, do not use]
smKeySwap 4 Keyboard swapping resource handle
The 'KSWP' resource handle is put here at boot time and switch-launch time. A 'KSWP' resource contains a table of key sequences that will cause the currently installed 'KCHR' (keyboard mapping table) to change to the preferred system 'KCHR', switch to the Roman 'KCHR', or rotate among the available 'KCHR' resources. The table includes the virtual key code and the modifier keys. The following is the 'KSWP' resource for the Kanji script interface system.
The resource says rotate 'KCHR' resources if a Space–Command key occurs, switch to the system 'KCHR' on keypad plus (+)–Command key, and switch to the Roman 'KCHR' on keypad asterisk (*)–Command key.
smGenFlags 4 General flags
Only the two high-order bits are defined (in the file ScriptEqu.a), as follows:
smfShowIcon = 31 (show icon even if only one script)
smfDualCaret = 30 (use dual caret for mixed direction text)
The high-order byte of smgrGenFlags, containing these flags, should be setup from the flags byte in the 'itlc' resource. This is not presently done, but will be fixed in future versions of the Script Manager.
The following MPW Pascal procedure demonstrates how to get script 'SICN' resources to display even if there is only one script system installed.
PROCEDURE SetSICN;
VAR
SICNstate: Longint;
err: Oserr;
BEGIN
SICNstate := GetEnvirons(smGenFlags);
BSET(SICNstate,smfShowIcon);
err := SetEnvirons(smGenFlags,SICNstate);
END;
smOverride 4 Script override flags
At present, this is not set or used by the Script Manager. It is, however, reserved for future improvements.
smCharPortion 2 Ch vs Sp Extra proportion, 4.12 fixed
This is 16-bit fixed-point value in 4.12 format (e.g., 10% = $0199). It is initialized to 10 percent at boot time. It is intended to be used by script systems to allocate space among intercharacter spacing and interword spacing when justifying text.
A 16-bit fixed-point value in 4.12 format is similar to the fixed-point number type defined on page I-79 of Inside Macintosh . The obvious difference being that it is only 16 bits long. The integer part of the value is stored in the high four bits, and the fractional part is stored in the low 12 bits.
16-bit Fixed-Point Number in 4.12 format
Local Variables
Every script interface system has local variables. Page V-132 of Inside Macintosh lists verbs which are constants that indicate which variable you want to read or set. The table of constants used to access the local variable, although more accurate than the global table, does contain a few inaccuracies. In addition four new constants have been added. Table 2 gives the correct constants.
Here again the descriptions are a little terse. The following section describes each variable in more detail and describes the size of each variable.
Verb Name Bytes Brief Description
smScriptVersion 4 Script Interface version number
When the script interface is loaded, this is set to the current version number.
smScriptMunged 2 Local modification count
This variable is incremented each time _SetScript is called.
smScriptEnabled 1 Script Enabled Flag
A Boolean which indicates whether the script has been enabled. Set to $FF when enabled and zero when not enabled.
smScriptRight 1 Right to Left Flag
A Boolean indicating if text should be drawn right to left or left to right. It is set to $FF for right to left text (Arabic and Hebrew scripts) and zero for left to right (Roman).
smScriptJust 1 Justification Flag
A byte flag which describes how text should be justified. The possible settings correspond to the justification flags used by TextEdit.
0 = left justification
1 = center justified
-1 = right justified
smScriptRedraw 1 Word Redraw Flag
A byte flag describing how much of a line should be redrawn when text is being entered.
0 Only draw a character
1 Redraw the entire word
-1 Redraw the entire line (Arabic)
smScriptSysFond 2 Preferred System Font
This is the font family ID for the preferred System Font. In a Roman system, ScriptSysFond is 0, the family ID for Chicago.
smScriptAppFond 2 Preferred Application Font
Font family ID for the preferred Application Font. In a Roman system, ScriptAppFond is 3, the family ID for Geneva.
smScriptNumber 4 Script 'itl0' ID
Resource ID of 'itl0' for this script. The 'itl0' resource describes how numbers and times should be displayed. The resource ID should match the country version code for a given country.
smScriptDate 4 Script 'itl1' ID
Resource ID of the 'itl1' for this script. The 'itl1' describes how dates should be displayed.
smScriptSort 4 Script 'itl2' ID
Resource ID of the 'itl2' for this script. The 'itl2' contains routines for sorting. See M.TE.NewStringComp.
smScriptFlags 2 Script flags
This verb provides access to the script flags word, which contains bit flags that describe features of the script. This word is initialized from the script’s 'itlb' resource. Constants specifying the bit numbers are described in Table 3.
Bit
Constant Number Description
smsfIntellCP 0 script has intelligent cut and paste
smsfSingByte 1 script has only single bytes
smsfNatCase 2 native characters have upper and lower case
smsfContext 3 contextual script (e.g., AIS-based)
smsfNoForceFont 4 will not force characters
smsfB0Digits 5 has alternative digits in B0-B9
smsfForms 13 uses contextual forms for letters
smsfLigatures 14 uses contextual ligatures
smsfReverse 15 reverses native text, right-left
Table 3–Constant Bit Numbers
smScriptToken 2 Script 'itl2' ID
Resource ID of the 'itl4' for this script. The 'itl4' contains contains tables needed by the number formatting and conversion routines and the _intlTokenize routine. See Script Manager 2.0, Interim Chapter.
smScriptRsvd 4 Reserved
smScriptLang 2 Script’s language code
This verb accesses a word which contains the current language code for the script. The language codes are defined in the MPW interface files.
smScriptNumDate 2 Number and date representation codes
This verb accesses a word containing the number and date representation codes for the script. The number representation code is in the high byte of the word, and the date code is in the low byte.
The possible values for number representations and date codes are declared as constants in the MPW interface files.
The number codes are: and the date codes are:
intWestern = 0; calGregorian = 0;
intArabic = 1; calArabicCivil = 1;
intRoman = 2; calArabicLunar = 2;
intJapanese = 3; calJapanese = 3;
intEuropean = 4; calJewish = 4;
calCoptic = 5;
smScriptKeys 4 Script 'KCHR' ID
Resource ID of preferred 'KCHR' resource. The 'KCHR' resource is used to map virtual key codes into the correct character code. See M.TB.KeyMapping.
smScriptIcon 4 Script 'SICN' ID
Resource ID of the small icon that is used to represent which country specific resources ('itl0', 'itl1', 'itl2', 'KCHR') are currently installed in the system. Presently, the Roman system does not display the 'SICN'. Arabic, Kanji, Chinese, and Hebrew interface systems do display this icon in the upper-right corner of the menu bar.
smScriptPrint 4 Script printer action routine
Print action routine vector; setup when script is installed by Script Manager. See M.TE.PrintAction.
smScriptTrap 4 Trap entry pointer
Pointer to Script dispatch routine. Script Manager routines always belong to one of two groups. The first group of routines are common to every script interface system, and the second group must be supplied by the script interface system. This variable will point to a dispatch routine for the interface-supplied routines. When you call _ScriptUtil, it looks at the selector that is passed and either calls a common routine or calls the routine whose address is stored in ScriptTrap. The routine in smScriptTrap will then use the selector to vector to the correct routine. In general, routines that display or measure text in some way will be supplied by the interface.
A list at the end of this Note indicates which routines are implemented by the Script Manager and which routines are supplied by a script interface system.
smScriptCreator 4 Script file creator
The four character creator type for the script interface’s file. For Roman it is “ZSYS,” the same creator as any system file has.
smScriptFile 4 Script file name
A pointer to the a Pascal string which contains the name of the file containing the script interface system. For the Roman SIS, it is System.
smScriptName 44 Script name
A pointer to a Pascal string which contains the script interface’s name. For Roman it is naturally, “Roman.”
Who Does What?
Table 4 breaks the documented routines into common Script Manager routines and interface specific routines.
Common Routines Interface Supplied
_FontScript _CharByte
_IntlScript _CharType
_KeyScript _Pixel2Char
_GetEnvirons _Char2Pixel
_SetEnvirons _Transliterate
_Font2Script _FindWord
_Format2Str _HiliteText
_FormatStr2X _DrawJust
_FormaX2Str _MeasureJust
_GetFormatOrder _ParseTable
_InitDateCache _VisibleLength
_IntlTokenize _FindScriptRun
_LongDate2Secs _PortionText
_LongSecs2Date
_Str2Format
_String2Date
_String2Time
_StyledLineBreak
_ToggleDate
Table 4–Script Manager Routines and Interface Specific Routines
_GetScript and _SetScript, which return the values of local script variables, are implemented by the Script Manager for some verbs and the script interface system for others.
There is also a group of Script Manager routines which don’t use the _ScriptUtil trap, but are documented in The Script Manager chapter of Inside Macintosh, Volume V-293 or The Script Manager 2.0 Interim Chapter. There routines are utilities that read and write to low-memory or PRAM. It is important to use these routines when they are available. That will allow Apple to modify where global variables, etc. are stored, and your application will remain compatible. The utilities are:
GetDefFontSize
GetSysFont
GetAppFont
GetMBarHeight
GetSysJust
SetSysJust
ReadLocation (documented in Interim Chapter)
WriteLocation (documented in Interim Chapter)
Further Reference:
• Inside Macintosh, Volume V-293, The Script Manager
• M.TB.KeyMapping
• M.TE.PrintAction
Modifying the Standard String Comparison
Text M.TE.NewStringComp
Revised by: March 1988
Written by: Mark Davis
Priscilla Oppenheimer November 1987
This technical note describes how to modify the standard string comparison by constructing an itl2 resource. Developers may want to modify the standard string comparison if Apple’s comparison doesn’t meet their needs or if Apple has not written a string comparison routine for the language that concerns them.
General Structure
The itl2 resource contains a number of procedures that are used for accurate comparison of text by the International Utilities Package. Refer to Inside Macintosh, volume V for an explanation of the algorithm used. The default itl2 for standard English text, which does no special processing, has the following form:
The comparison hook procedures are all assembly language based, with arguments described below. Since the routines may be called once per character in both strings, the routines should be as fast as possible.
The condition codes are used to return information about the status of the hook routine. Typically the normal processing of characters will be skipped if the CCR is set to NE, so the default return should always have EQ set. Each of these routines has access to the stack frame (A6) used in the comparison routine, which has the following form:
IUSortFrame Record {oldA6},Decrement
result ds.w 1
argTop equ *
aStrText ds.l 1
bStrText ds.l 1
aStrLen ds.w 1
bStrLen ds.w 1
argSize equ argTop-*
return ds.l 1
oldA6 ds.l 1
aInfo ds IUStrData
bInfo ds IUStrData
wantMag ds.b 1 ; 1-MagStrig 0-MagIdString.
weakEq ds.b 1 ; Signals at most weak equality
msLock ds.b 1 ; high byte of master ptr.
weakMag ds.b 1 ; -1 weak, 1 strong compare
supStorage ds.b 18 ; extra storage.
localSize equ * ; frame size.
EndR
There are three fields in this frame that are of interest for altering text comparison. The supStorage field is an area reserved for use by the comparison hook procedures as they see fit. The aInfo and bInfo records contain information about the current byte positions in the two compared strings A and B, and information about the status of current characters in those string. The IUStrData record has the following form:
IUStrData Record 0
curChar ds.w 1 ; current character.
mapChar ds.w 1 ; projected character.
decChar ds.w 1 ; decision char for weak equality
bufChar ds.b 1 ; buffer for expansion.
justAfter ds.b 1 ; boolean for AE vs ligature-AE.
ignChar ds.b 1 ; flag: ignore char.
noFetch ds.b 1 ; flag: no fetch of next.
strCnt ds.w 1 ; length word.
strPtr ds.l 1 ; current ptr to string.
EndR
The Init Procedure
The Init Procedure is used to initialize the comparison process. The main use for this procedure is for double-byte scripts. As an optimization, the International Utilities will perform an initial check on the two strings, comparing for simple byte-to-byte equality. Thus any common initial substrings are checked before the Init procedure is called. The string pointers and lengths in the IUStrData records have been updated to point just past the common substrings.
Languages such as Japanese or Yugoslavian, which may consider two bytes to be one character, may have to back up one byte, as shown below.
; Note: this should also check for single-byte nigori or maru, as below
InitProc
move.w AStrLen(a6), d0 ; A length
sub.w AInfo.StrCnt(a6),d0 ; see if its changed
beq.s @FixB ; A is done if not
sub.l #2,sp ; return param
move.l AStrText(a6),-(sp) ; textBuf
move.w d0,-(sp) ; textOffset
_CharByte
tst.w (sp)+ ; on character boundary?
ble.s @FixB ; yes, continue
sub.l #1,AInfo.StrPtr(A6) ; adjust pointer
add.w #1,AInfo.StrCnt(A6) ; adjust count
@FixB
move.w BStrLen(a6), d0 ; B length
sub.w BInfo.StrCnt(a6),d0 ; see if its changed
beq.s Quit Init ; B is done if not
sub.l #2,sp ; return param
move.l BStrText(a6), -(sp) ; textBuf
move.w d0, -(sp) ; textOffset
_CharByte
tst.w (sp)+ ; on character boundary?
ble.w @QuitInit ; yes, continue
sub.l #1,BInfo.StrPtr(A6) ; adjust pointer
add.w #1,BInfo.StrCnt(A6) ; adjust count
@QuitInit
bra.s ReturnEQ ; return to the caller.
EndWith
The Fetch Procedure
The Fetch Procedure is used to fetch a character from a string, updating the pointer and length to reflect the remainder of the string. For example, the following code changes the text comparison for Yugoslavian:
; if we have a double-byte char, add the second byte
lea CurChar(a2),a0 ; pass pointer
move.w d4,(a0) ; set value at ptr
clr.w d0 ; pass length
sub.l #2,SP ; allocate return
move.l a0,-(sp) ; pointer
move.w d0,-(sp) ; offset
_CharByte
tst.w (sp)+ ; test return
bmi.s @DoubleByte ; skip if high byte (first two)
; we don’t have a double byte, but two special cases combine second bytes
move.b (a3),d0 ; get next byte
cmp.b #$DE,d0 ; nigori?
beq.s @DoubleByte ; add in
cmp.b #$DF,d0 ; maru?
bne.s ReturnEq ; exit: single byte
@DoubleByte
move.b (a3)+,d4 ; get next byte
subq.w #1,StrCnt(A2) ; dec string length
addx.w d5,d5 ; set x=1 if string len = 0
rts ; return to caller with CCR=NE
The Project Procedure
The Project Procedure is used to find the primary ordering for a character. This routine will map characters that differ only in the secondary ordering onto a single character, typically the unmodified, uppercase character. For example, the following changes the comparison order for some Norwegian characters, so that they occur after ‘Z.’
; Table contains entries of the form r1, r2, o1, o2,
; where r1,r2 are the replacement word, and
; o1, o2 are the original character.
; The entries are sorted by o1,o2 for use in the above algorithm
DC.B 'Z', 3, 'Å', 0 ; Å after Ø
DC.B 'Z', 3, 'å', 0 ; å after Ø
DC.B 'Z', 1, 'Æ', 0 ; Æ after Z
DC.B 'Z', 2, 'Ø', 0 ; Ø after Æ
DC.B 'Z', 1, 'æ', 0 ; æ after Z
DC.B 'Z', 2, 'ø', 0 ; ø after Æ
DC.L $FFFFFFFF ; table end
The Project procedure can also be used to undo the effects of the normal projection. For example, suppose that “œ” is not to be expanded into “oe”: in that case, a simple test can be made against 'œ',0, returning NE if there is a match, so that the normal processing is not done. To expand one character into two, the routine should return the first replacement character in D4.W, and modify two fields in the IUStrData field. For example, given that A1 points to a table entry of the form (primaryCharacter: Word; secondaryCharacters: Word), the following code could be used:
…
move.w (a1)+,d4 ; return first, primary character
move.w (a1)+,CurChar(A2) ; original => first, modified char.
addq.b #1,JustAfter(A2) ; set to one (otherwise zero)
move.b (a1),BufChar(A2) ; store second character (BYTE!)
…
CurChar is where the original character returned by FetchChar is stored. If characters are different even after being projected onto their respective primary characters, then the CurChar values for each string will be compared. JustAfter indicates that the expanded character should sort after the corresponding unexpanded form. This field must be set whenever CurChar is modified in order for the comparison to be fully ordered. BufChar stores the next byte to be retrieved from the string by FetchChar.
To handle the case where characters are ignored unless the two compared strings are otherwise equal, the IgnChar flag can be set. This can be used to handle characters such as the hyphen in English, or vowels in Arabic.
…
cmp.w #hyphen,d0 ; is it a ignorable?
seq IgnChar(a2) ; set whether or not
…
The Vernier Procedure
The Vernier Procedure is used to make a final comparison among characters that have the same primary ordering. It is only needed if the CurChar values are not ordered properly. For example, according to the binary encoding, å < Ã. To change this ordering so that uppercase letters are before lowercase letters, Ã is mapped to $7F in normal comparison. Notice that only the characters in the secondary ordering are affected: Ã can be mapped onto Z, but not onto Ä, since that would cause a collision.
To write an itl2 resource, follow the guidelines in M.PT.StandAloneCode for writing standalone code in MPW. The code should be written in assembly language, and it must follow the specifications given in this technical note or serious system errors could occur whenever string comparisons are made.
The default comparison routine is in the itl2 resource of the System file. In order to use a comparison routine other than the standard one, you should include an itl2 resource in your application with the same name and resource ID as the one in the System file that you wish to change. The Resource Manager will look for the resource in the application resource file before it looks in the System resource file, so your string comparison routine will be used instead of the default one.
It is generally a dangerous practice to change a system resource since other applications may depend on it, but if you have good reasons to permanently change the system itl2 resource so that all applications use a different comparison routine, then you should write an installer script to change the itl2 resource in the System resource file. Writing an installer script is documented in M.TP.Installer. You are required to write an installer script if you are planning to ship your application on a licensed system software disk and your application makes a permanent change to any resources in the System file. We strongly discourage changing the System itl2 as that would change the behavior of string comparison and sorting for all applications. If that is your intent, then you should write an installer script. However, if you are changing the itl2 resource in the System file for academic or internal use, then you can use a resource editor such as ResEdit to copy your itl2 resource into the System file.
Further Reference:
• The International Utilities
• M.TP.Installer
• M.PT.StandAloneCode
Styled TextEdit Changes in System 6.0
Text M.TE.TextEditChanges
Revised by: Chris Derossi December 1988
Written by: Chris Derossi August 1988
Some changes were made to TextEdit in System 6.0 to provide more functionality and to make life easier for the programmer using TextEdit. This Note documents those changes and enhancements.
Changes since August 1988: Corrected an error in TEDispatchRec in the figure on page 8.
TextEdit Changes
In order to improve the usability of styled TextEdit, some routines have been changed, and some new routines have been added. These changes exist in System Software 6.0 and later. If you intend to rely on any of these changes or new routines, it is important that you call _SysEnvirons first to make sure you are running under System Software 6.0 or later.
_SysEnvirons is documented in Inside Macintosh, Volume V and M.OV.GestaltSysenvirons. To check for the styled TextEdit changes, you might do the following:
VAR
theWorld: SysEnvRec;
anErr : OSErr;
BEGIN
anErr := SysEnvirons(1, theWorld);
IF (anErr = noErr) AND (theWorld.systemVersion >= $0600) THEN …
{System 6.0 or later}
END;
Changes to Existing Routines
_TEKey and _TEDelete have been changed so that backspacing to the beginning of a style no longer deletes that style. Instead, the style is saved in the nullScrap to be applied to subsequently typed characters. As soon as the user has backspaced past the beginning of the style, or clicked in some other area of the text, the style is removed.
GetStylScrap now returns a handle to a valid style scrap record when called for an insertion point (selStart = selEnd). NIL is still returned when GetStylScrap is called with an old style TEHandle.
TESetStyle now accepts an additional mode, doToggle (= 32). When doToggle is specified along with doFace, TESetStyle operates as follows: If a style specified in the given TextStyle parameter exists across the entire selected range, that style is removed (turned off). Otherwise, all of the selected text is set to include that style. When a particular style is set for an entire selection range, that style is said to be continuous over the selection.
For example, given that the following text is the current selection:
then the style bold is continuous over the selection range and the italic style is not. If TESetStyle were called with a mode of doFace + doToggle and a TextStyle tsFace field of [bold], then the resulting selection would be:
On the other hand, if TESetStyle had been called with a mode of doFace + doToggle and a TextStyle tsFace field of [italic], then the selected text would have become:
New TextEdit Routines
Some new routines have been added to TextEdit, TEContinuousStyle, SetStylScrap, TECustomHook, and TENumStyles. These routines are described in detail below.
Assembly language note:
The new TextEdit routines are called via the _TEDispatch trap. Following are the decimal selectors for the new routines:
TEContinuousStyle 10
SetStylScrap 11
TECustomHook 12
TENumStyles 13
TEContinuousStyle
FUNCTION TEContinuousStyle(VAR mode : Integer; VAR aStyle : TextStyle;
hTE : TEHandle) : Boolean;
TEContinuousStyle gives you information about the attributes of the current selection. The mode parameter, which takes the same values as in TESetStyle, specifies which attributes should be checked. When TEContinuousStyle returns, the mode parameter indicates which of the checked attributes is continuous over the selection range and the aStyle parameter is set to reflect the continuous attributes.
TEContinuousStyle returns TRUE if all of the attributes to be checked are continuous and FALSE if not. In other words, if the mode parameter is the same before and after the call, then TEContinuousStyle returns TRUE.
For example, TEContinuousStyle is useful for marking the style menu items based on the current selection.
mode := doFace;
IF TEContinuousStyle(mode, aStyle, myTE) THEN BEGIN
{ There is at least one face that is continuous over the
selection. Note that it might be plain which is actually
CheckItem(styleMenu, boldItem, bold IN aStyle.tsFace);
CheckItem(styleMenu, italicItem, italic IN aStyle.tsFace);
...etc.
END ELSE BEGIN
{ No text face is common to the entire selection. }
CheckItem(styleMenu, plainItem, FALSE);
CheckItem(styleMenu, boldItem, FALSE);
CheckItem(styleMenu, italicItem, FALSE);
...etc.
END;
This function can also be used to determine the actual values for those attributes that are continuous for the selection. Note that a field in the TextStyle record is only valid if the corresponding bit is set in the mode variable; otherwise the field contains garbage. For example, to determine the font, face, size, and color of the current selection:
{ aStyle.tsFace contains the text faces (or plain) that are
common to the selection. }
ELSE
{ No text face is common to the entire selection. };
IF BitAnd(mode, doSize) <> 0 THEN
{ Size for selection = aStyle.tsSize. }
ELSE
{ More than one size in selection. };
IF BitAnd(mode, doColor) <> 0 THEN
{ Color for selection = aStyle.tsColor. }
ELSE
{ More than one color in selection. };
The aStyle.tsFace field is a bit tricky. When TEContinuousStyle returns a mode that contains doFace, and an aStyle.tsFace field that contains [bold, italic], it means that the selected text is all bold and all italic, but may contain other text faces as well. None of the other faces will apply to all of the selected text, or they would have been included in the tsFace field. But if the tsFace field is the empty set ([] = plain), then all of the selected text is plain.
If the current selection range is an insertion point, TEContinuousStyle returns the style information for the next character to be typed. TEContinuousStyle will always return TRUE in this case, and each field of the TextStyle record will be set if the corresponding bit in the mode parameter was set.
SetStylScrap performs the opposite function of GetStylScrap. The newStyles parameter is a handle to a style scrap record which will be applied over the given range of text. The current selection range is not changed. If newStyles is NIL or hTE is a handle to an old style TERecord, SetStylScrap does nothing.
SetStylScrap will terminate without error if it prematurely reaches the end of the range or if there are not enough scrap style elements to cover the whole range. In the latter case, the last style in the scrap record will be applied to the remainder of the range.
TENumStyles
FUNCTION TENumStyles(rangeStart, rangeEnd : LongInt;
hTE : TEHandle) : LongInt;
This function returns the number of style changes contained in the given range, counting one for the start of the range. Note that this does not necessarily represent the number of unique styles for the range, because some styles may be repeated. For old-style TextEdit records, this function always returns 1.
This function is useful for calculating the amount of memory that would be required for a contemplated _TECut or _TECopy. Since the style scrap record is linear in nature, with one element for each style change, you can multiply the result returned by TENumStyles by SizeOf(ScrpSTElement) and add 2 to get the amount of memory that will be needed.
TECustomHook
PROCEDURE TECustomHook(which : TEHook; VAR addr : ProcPtr;
hTE : TEHandle);
This procedure lets applications customize the functions of TextEdit by setting the TextEdit bottleneck routines. The which parameter specifies which bottleneck routine to replace, and is of type TEHook (described below). When TECustomHook returns, the addr parameter contains the address of the previous bottleneck routine specified by which. This is returned so that bottleneck routines can be daisy-chained.
The internally used fields, recalBack and recalLines now form a handle to the list of TextEdit bottleneck routines. Each TERecord has its own set of bottleneck routines to provide for maximum flexibility. The TECustomHook procedure should always be used to change the bottleneck routines instead of modifying the edit record directly.
Also, it is important to note that you should not clone a TERec. Doing so would duplicate the handle stored in recalBack and recalLines. When one of the TextEdit records was disposed, the handle stored in the copy would be invalid, and TextEdit would crash.
There are four bottleneck routines, TEEOLHook, TEWidthHook, TEDrawHook, and TEHitTestHook, described individually below. When replacing these routines, note that all registers except those specified as containing return values must be preserved. Registers A3 and A4 contain a pointer and a handle to the TextEdit record respectively. Line start positions can be obtained from the lineStarts array in the edit record.
None of these bottleneck routines are called from _TextBox.
TEEOLHook
This routine tests a given character and returns with the appropriate status flags set in the status register. The default action is to merely compare the character with $0D (a carriage return) and return.
On entry: D0 character to compare (byte)
A3 pointer to the TextEdit record (long)
A4 handle to the TextEdit record (long)
On exit: z flag clear if end-of-line character, set otherwise
TEWidthHook
This routine is called any time the width of various components of a line are calculated. The appropriate font, face, and size characteristics have already been set into the current port by the time this routine is called. The default action is to call _Char2Pixel and return.
On entry: D0 length of text to measure (word)
D1 offset into text (word)
A0 pointer to text to measure (long)
A3 pointer to the TextEdit record (long)
A4 handle to the TextEdit record (long)
On exit: D1 width of measured text (word)
TEDrawHook
This routine is called any time the various components of a line are drawn. The appropriate font, face, and size characteristics have already been set into the current port by the time this routine is called. The default action is to call _DrawText and return.
On entry: D0 offset into text (word)
D1 length of text to draw (word)
A0 pointer to text to draw (long)
A3 pointer to the TextEdit record (long)
A4 handle to the TextEdit record (long)
TEHitTestHook
This routine is called to determine the character position in a line given the horizontal offset, in pixels, from the beginning of a line. The default action is to call _Pixel2Char and return. For more information, see the description of _Pixel2Char in the Script Manager chapter of Inside Macintosh, Volume 5 and the Inside Macintosh Interim Chapter Draft, Script Manager 2.0.
On entry: D0 length of text to hit test (word)
D1 pixel offset from start of text (word)
A0 pointer to start of text (long)
A3 pointer to the TextEdit record (long)
A4 handle to the TextEdit record (long)
On exit: D0 pixel width to last offset (low word)
Boolean = TRUE if a character (high word)
offset corresponding to the pixel width was found.
D1 character offset (word)
D2 Boolean = TRUE if the pixel (word)
offset falls within the left side of the character.
TextEdit Data Structures
The illustration on the following page is a graphic representation of the TextEdit data structures. You should use this information only for debugging and so you understand what is going on. For reading or writing these data structures, the TextEdit routines should be used. This will help ensure future compatibility.
Further Reference:
• M.OV.GestaltSysenvirons
TEScroll Bug
Text M.TE.TEScrollBug
Revised by: March 1988
Written by: Bryan Stearns April 1986
A bug in TextEdit causes the following problem: a call to TEScroll with no horizontal or vertical displacement (that is, both dh and dv set to zero) results in disappearance of the insertion point. Since such calls do nothing, they should be avoided:
IF (dh <> 0) OR (dv <> 0) THEN TEScroll(dh,dv,myTEHandle);
Further Reference:
• TextEdit
• M.TE.TextEditBugs
TextEdit: Advice & Descent
Text M.TE.TextEditAdvice
Revised by: March 1988
Written by: Rick Blair June 1986
This technical note will point out some bugs (and possible workarounds), and other items of interest for the TextEdit programmer.
TESelRect
Multiple line selections are often more complex shapes than simple rectangles. If this is the case, the teSelRect field of the TERec is set to the last (bottommost) rectangle in the selection. The teHiHook is called to invert each line of the selection.
The ROM limits the selection range (i.e. the lines that get set into teSelRect) to only those lines which will fit into the viewRect. This means that teSelRect will be left at the last visible line. (The old 64K ROMs made all the calls for the complete selection and just let clipping take care of the rest.)
TEDoText
The parameters of this special hook into TextEdit need a little additional explanation. D3 and D4 are described on page 391 of Inside Macintosh Volume I as being the first and last characters to be redrawn. This is true but specific to the –1 “DoDraw” case. In fact, all the calls to TEDoText are interested in these first and last character positions. They determine the selection for a (1) highlight call, the caret position for a (–2) DoCaret call (where D4 is ignored as it’s assumed to equal D3), etc.
Note that the DoCaret (–2) call behaves differently than described in Inside Macintosh, as well. Good old page 391 says it sets up the pen position for caret drawing. Since an InvertRect call is used to draw the caret if you use the default teCarHook, the ROMs just set up teSelRect, they don’t bother with the QuickDraw pen.
TEScrpLength
Inside Macintosh describes TEScrpLength as a long integer; indeed, four bytes are reserved for this value with the intent of someday using that range of values. However, the ROMs use word operations in their accesses to TEScrpLength and make word calculations with it. This means that the high word of TEScrpLength is used for calculations. This is something to watch out for.
CharWidth
Inside Macintosh says that CharWidth takes stylistic variations into account when determining the width of a character. In fact, for italic and outlined styles the extra width is not taken into account. TextEdit relies on CharWidth for positioning of the caret, etc. If you have chosen to use, for instance, italic style in your TE record you will find that as you type the caret actually overlaps the character to the left and so when the caret is erased some of that character will get erased, too. This is somewhat disconcerting to the user but the program will still function correctly.
Clikloops
If you add your own click loop and try to do something like update scroll bars you may run into trouble. Before your routine gets called, TextEdit will have set clipping down to just the viewRect. You will have to save away the old clipping region, set it out to sufficient size (–32767, –32767, 32767, 32767 is probably OK), do your drawing, then restore TextEdit’s clipping area so that it can function properly.
Further Reference:
• TextEdit
• M.TE.TEScrollBug
• M.TE.EOLAmbiguity
• M.TE.TextEditBugs
TextEdit Bugs in System 4.2
Text M.TE.TextEditBugs
Revised by: March 1988
Written by: Chris Derossi June 1987
This note formerly described the known bugs with the version of Styled TextEdit that was provided with System 4.1. Many of these bugs were fixed in System 4.2. This updated Technical Note describes the remaining known problems.
TEStylInsert
Calling TEStylInsert while the TextEdit record is deactivated causes unpredictable results, so make sure to only call TEStylInsert when the TextEdit record is active.
TESetStyle
When using the doFace mode with TESetStyle, the style that you pass as a parameter is ORed into the style of the currently selected text. If you pass the empty set (no styles) though, TESetStyle is supposed to remove all styles from the selected text. But TESetStyle checks an entire word instead of just the high-order byte of the tsFace field. The style information is contained completely in the high-order byte, and the low-order byte may contain garbage.
If the low-order byte isn’t zero, TESetStyle thinks that the tsFace field isn’t empty, so it goes ahead and ORs it with the selected text’s style. Since the actual style portion of the tsFace field is zero, no change occurs with the text. If you want to have TESetStyle remove all styles from the text, you can explicitly set the tsFace field to zero like this:
VAR
myStyle : TextStyle;
anIntPtr : ^Integer;
BEGIN
...
anIntPtr := @myStyle.tsFace;
anIntPtr^ := 0;
TESetStyle(doFace, myStyle, TRUE, textH);
...
END;
TEStylNew
The line heights array does not get initialized when TEStylNew is called. Because of this, the caret is initially drawn in a random height. This is easily solved by calling TECalText immediately after calling TEStylNew. Extra calls to TECalText don’t hurt anything anyway, so this will be compatible with future Systems.
An extra character run is placed at the beginning of the text which corresponds to the font, size, and style which were in the grafPort when TEStylNew was called. This can cause the line height for the first line to be too large. To avoid this, call TextSize with the desired text size before calling TEStylNew. If the text’s style information cannot be determined in advance, then call TextSize with a small value (like 9) before calling TEStylNew.
TEScroll
The bug documented in M.TE.TEScrollBug remains in the new TextEdit. TEScroll called with zero for both vertical and horizontal displacements causes the insertion point to disappear. The workaround is the same as before; check to make sure that dV and dH are not both zero before calling TEScroll.
Growing TextEdit Record
TextEdit is supposed to dynamically grow and shrink the LineStarts array in the TERec so that it has one entry per line. Instead, when lines are added, TextEdit expands the array without first checking to see if it’s already big enough. In addition, TextEdit never reduces the size of this array.
Because of this, the longer a particular TextEdit record is used, the larger it will get. This can be particularly nasty in programs that use a single TERec for many operations during the program’s execution.
Restoring Saved TextEdit Records
Applications have used a technique for saving and restoring styled text which involves saving the contents of all of the TextEdit record handles. When restoring, TEStylNew is called and the TextEdit record’s handles are disposed. The saved handles are then loaded and put into the TextEdit record. This technique should not be used for the nullStyle handle in the style record.
Instead, when TEStylNew is called, the nullStyle handle from the style record should be copied into the saved style record. This will ensure that the fields in the null-style record point to valid data.
TextEdit Conversion Utility
Text M.TE.TextEditConvert
Revised by: March 1988
Written by: Harvey Alcabes April 1985
Text sometimes must be converted between a Pascal string and “pure” text in a handle. This note illustrates a way to do this using MPW Pascal.
Text contained in TextEdit records sometimes must be passed to routines which expect a Pascal string of type Str255 (a length byte followed by up to 255 characters). The following MPW Pascal unit can be used to convert between TextEdit records and Pascal strings:
UNIT TEConvert;
{General utilities for conversion between TextEdit and strings}
INTERFACE
USES MemTypes,QuickDraw,OSIntf,ToolIntf;
PROCEDURE TERecToStr(hTE: TEHandle; VAR str: Str255);
{TERecToStr converts the TextEdit record hTE to the string str.}
{If necessary, the text will be truncated to 255 characters.}
PROCEDURE StrToTERec(str: Str255; hTE: TEHandle);
{StrToTERec converts the string str to the TextEdit record hTE. }
IMPLEMENTATION
PROCEDURE TERecToStr(hTE: TEHandle; VAR str: Str255);
• Macintosh Memory Management: An Introduction TextEdit
TextEdit EOL Ambiguity
Text M.TE.EOLAmbiguity
Revised by: March 1988
Written by: Rick Blair May 1987
TESetSelect may be used to position the insertion point at the end of a line. There is an ambiguity, though; should the insertion point appear at the end of the preceding line or the start of the following one? It is possible to determine what will happen, as you are about to see.
There is an internal flag used by TextEdit to determine where the insertion point at the end of a line appears. This flag is part of the clikStuff field in the TERec. It is there mainly for the use of TEClick, but it is also used by TESetSelect (although it defaults to the right side of the previous line).
The following code can be used to force the insertion point to appear at the left of the following line when it is positioned at the end of a line; in MPW Pascal:
This Technical Note describes another limit on the length of a TextEdit record that was previously undocumented.
The TextEdit chapters in Inside Macintosh document the 32K character limit on a TextEdit record length. They do not, however, discuss the more subtle constraint on the size of the destRect. By definition, the destRect uses integer values for the top-left and bottom-right boundary points. It is possible to have values too large for the destRect without reaching the teLength limit.
The nLines field gives the number of lines in the edit record, and the lineHeight field specifies the vertical distance from the ascent line from one line of text to the ascent line of the next line. In styled TextEdit, the lineHeight may vary for each line depending on the font and font size. These values are entries in the lineHeight table.
Figure 1–LineHeight
The product of the lineHeight (or the largest lineHeight value in styled TextEdit) and nLines gives a good approximation, in pixels, of the vertical dimension of the destRect of the TERec used. If this value is greater than 32,768, then unpredictable and erratic behavior may result.
For example:
2,400 lines of Chicago 12 point yields nLines = 2,400 and lineHeight = 16.
nLines * lineHeight = 2400 * 16 = 38,400. This is above the 32K limit.
1,200 lines of Times 24 point yields nLines = 1,200 and lineHeight = 30.
nLines * lineHeight = 1200 * 30 = 36,000. This is above the 32K limit.
In both of the examples above, the number of characters in the edit record was less than 32,768.
Check All Constraints
Both TELength and the size of the destRect must be under the 32K limit. You can compute an approximate vertical height of the destRect by finding the product of nLines and lineHeight (or the largest lineHeight value in styled TextEdit).
Revised by: Developer Support Center December 1992
Written by: Developer Support Center October 1990
This Technical Note contains a collection of Q&As relating to a specific topic—questions you’ve sent the Developer Support Center (DSC) along with answers from the DSC engineers. While DSC engineers have checked the Q&A content for accuracy, the Q&A Technical Notes don’t have the editing and organization of other Technical Notes. The Q&A function is to get new technical information and updates to you quickly, saving the polish for when the information migrates into reference manuals.
Q&As are now included with Technical Notes to make access to technical updates easier for you. If you have comments or suggestions about Q&A content or distribution, please let us know by sending an AppleLink to DEVFEEDBACK. Apple Partners may send technical questions about Q&A content to DEVSUPPORT for resolution.
New Q&As this month:
Extending TextEdit beyond 32K limit
Controlling TEIdle’s insertion point color
Extending TextEdit beyond 32K limit
Date written: 9/16/92
Last reviewed: 11/1/92
How do I get around the 32K limit in TextEdit? For example, if I have a 64K text file and I want to read it in and display it in a window, I can only read the first 32K. How do I make the text display smoothly when I need to read the next block of text in?
___
Unfortunately, there’s no supported way of doing this. In the early days, TextEdit was designed for use primarily with the Dialog Manager, for displaying and editing small amounts of text at a time. Since then, many developers have used it, or wanted to use it for much more than it was intended. See the Technical Note “Don’t Abuse the Managers,” available on the Developer’s CD, (path: “Dev.CD Sept 92:Technical Documentation:Macintosh Technical Notes:Overview:Managerial Abuse”).
The Word Solution Engine by DataPak is a replacement for TextEdit that allows you to go beyond the 32K limit, as well as including many other features. Other packages are available as well. Check the Redgate Macintosh Directory on AppleLink or publications such as MacTutor magazine to find them.
Controlling TEIdle’s insertion point color
Date written: 7/6/92
Last reviewed: 11/1/92
Is it possible to control the color of the insertion point when I use TEIdle? If I have a light blue background color, the caret is always the invert of that background color and doesn’t have enough contrast to see it. I want to make the color of the caret black if possible.
___
As is often the case, some of the seemingly simplest questions tend to yield the most interesting answers. Succinctly, your question stabs at the wobbly knees of QuickDraw’s color model. Sample code to change the color of the caret in a TextEdit record is in the Snippets folder. Here’s how to implement the color caret.
You can use the caretHook field of the TextEdit record (IM I-379). Basically, this procedure is called repeatedly by TEIdle to draw the caret. The function calls InvertRect each time. It draws the caret, and then it erases the caret. Unfortunately, this function needs to be implemented in assembly. So there are a few gotchas:
• The pointer to the rectangle for the caret is passed on the stack (not the whole rectangle).
• The function InvertRect becomes _InverRect in assembly.
• You can only use A4 for scratch (A0 and A1 are blown away by PaintRect), and then only if you saved and restore it.
• Make sure you pop off the rectangle pointer if you do not use it.
The default system function is simply _InverRect because the rectangle pointer is on the stack and _InverRect pops it off. For color, inverting is not the best idea, as you have noted. Inversion, if it isn’t black and white, does not give you the most contrast. Thus, we need another idea.
But, remember, we have a requirement to paint once, and then erase on the next pass. Inversion works nicely this way. To meet this requirement, use Xor mode with PaintRect. As you know, Xor mode is “or” mode with the double 1s being set to 0 instead of 1. This trait is ideal in your situation because, always having the same caret pattern, drawing a second time obliterates the previous drawing of the caret. Thus, we get the blinking behavior. And, with the Macintosh II and Color QuickDraw, we get these cool things called pixel patterns (IM V-55). You can use your own pixel pattern as the pen pattern, bring it in from the resource, and then use PaintRect in the patXor mode to achieve the desired effect. Done, right?
Unfortunately, here we run into a major flaw of QuickDraw: It is based on two color models, indexed and direct. And, arithmetic operations are performed on the pixel values, and not the colors. In the indexed model, a pixel value of 0x00 is white. (The pixel value in the indexed color model is really an index into a color table.) If you Xor it with 0xFF, you’ll get 0xFF, or black. If you Xor 0xFF with 0xFF, you’ll get 0x00 or white again. On the other hand (in the direct color model), a pixel value of 0x00 is black. If you Xor it with 0xFF, you’ll get 0xFF, or white. This is a problem.
So, you’ll need to perform conditional caret coloring (sounds like a disease). Depending on the depth, you’ll need to use a different pixel pattern. One good way is to use DeviceLoop (Inside Macintosh Volume VI, page 21-23). Though it’s included with System 7.0, there’s a simulated one as described in the article “Multiple Screens Revealed” on page 57 of develop #10. DeviceLoop lets you provide a routine that is called for each screen that the drawing area touches. In this case, the drawing routine is your PaintRect routine for the caret. This drawing routine gets passed the depth of the screen. So, based on the depth of the screen, you can use a different pixel pattern to draw with. For pixel depth of 32 or direct color mode, you can use one pattern, and for the rest you can use a different pattern.
Note, the drawing routine used by DeviceLoop allows you to pass in a LONGINT of userdata. With this longint, you can pass in the pointer to the rectangle from the assembly routine.
Resizing a Macintosh edit field for TEPaste
Written: 11/27/91
Last reviewed: 11/27/91
I have a small edit field and when I call TEPaste, the edit field contents scroll up. How can I calculate what the height of the edit field would be after the paste, resize the edit field to be that size, and then do the paste?
___
There are a couple of ways to implement this:
Method #1:
1. Set the clip region to something other than the viewRect of the edit field.
2. Call TEPaste or TEStylPaste to insert the clipboard text.
3. Call TEGetHeight to get the new height of the text.
4. Set the viewRect of the TERec to the new height. Call TECalText for good measure (and good lineStarts).
5. Finally, set the clip region back to normal and call TEUpdate.
Method #2:
1. Call TENew or TEStylNew to allocate a brand spankin’ new temporary TERec, and give it a viewRect and destRect that’s off the screen but that has the same width as the original TERec.
2. Next, copy the hText handle of the window’s TERec into the hText field of the temporary TERec (good job for BlockMove [IM II-44]).
3. Call TECalText and TEActivate on it; then paste the clipboard text into the temporary TERec. Since the view and dest Rects are off the screen, none of this will be seen by the user.
4. Call TEGetHeight to get the new height, then copy the text back into the original TERec.
5. Finally, call TECalText, then TEUpdate and TEActivate on the original TERec.
Method #1 has less overhead and is a little easier to implement. However, if you have any custom hooks installed in your TERec, then you probably want to let TextEdit do as much of the work as possible. In this case, method #2 is a better way.
Saving and restoring styled Macintosh TextEdit records
Written: 11/26/90
Last reviewed: 12/19/90
How do I save and restore Macintosh records created with TextEdit that contain styles? Where can I find additional information or sample code?
___
There’s no standard for saving text with styles created by TextEdit, so all we can offer is a recommendation that’s modeled after the way that TECopy works on styled text. In styled TextEdit, the style information is stored separately from the text rather than embedded within it. TECopy maintains this separation when styled text is copied, so our recommendation maintains this separation, too.
To save the text part, you could make a file of type TEXT and save the text in the data fork of the file, like TeachText does. You could also save it in a resource of type TEXT.
The best way to save the style information is to use the StScrpRec record. Other records used by styled TextEdit contain references to other structures or they contain only a part of the style information, and that makes saving them awkward. The StScrpRec doesn’t contain references to any other structures, and it contains enough information to rebuild the entire tree of TextEdit structures. When you call TECopy on styled text, both a 'TEXT' and 'styl' scrap type is placed into the desk scrap. The 'TEXT' type just contains the text. The 'styl' type contains a StScrpRec containing all of the style information for the copied text. TextEdit doesn’t maintain a StScrpRec for the entire text buffer, so you have to tell TextEdit to do this for you when you’re ready to save the style information.
Fortunately, one call does it all. Inside Macintosh Volume V, page 268, documents the GetStylScrap routine. It creates a new StScrpRec record, places all the style information of the selected text into it, and returns a handle to this StScrpRec. First, select the text you want to save either by calling TESetSelect or by setting the selStart and selEnd fields of the TextEdit record if you don’t want the selection to be visible to the user. (If you do this, remember to restore the old values of selStart and selEnd after you get the StScrpHandle.) Next, call GetStylScrap to construct the StScrpRec. You can now save the resulting StScrpRec, perhaps in a resource of type 'styl' or in whatever way you see fit.
Reading the text and styles back into a TextEdit record isn’t much more complicated. First, read the text back into a buffer and read the 'styl' resource (or however you saved it) into a StScrpRec. Create a styled TextEdit record (or use an old one), then call TEStylInsert, passing it a pointer to the text buffer and a handle to the StScrpRec. Your TextEdit record should then contain and display your original styled text. That’s all!
Macintosh SetClikLoop procedure and TERec clikLoop field
Written: 7/30/91
Last reviewed: 8/1/91
I have had some problems with the SetClikLoop procedure that don’t appear when I set the clikLoop field directly (in C). Why does TextEdit’s SetClikLoop procedure create a special procedure to call my clikLoop routine, rather that just installing the clikLoop directly? Inside Macintosh says you can set the clikLoop field directly in assembly. Why not in C?
___
The short answer is that the special procedure is a glue routine for shuttling a result between the stack and the register D0. The larger question is why does installing clikLoop directly work? C, I think, is the culprit.
But, before I get ahead of myself, let me explain the SetClikLoop procedure. As you know, the click loop routine has no parameters but it does return a Boolean result (IM I-380).
FUNCTION MyClikLoop : Boolean; { Pascal declaration }
pascal Boolean MyClikLoop(); { C declaration }
Now, MyClikLoop is called by the TextEdit Manager from inside the TEClick routine. The way the code was written, TEClick expects to get the Boolean result from D0. For assembly programmers, this is no problem. In Pascal, the return value is placed on the stack. So, D0 does not contain your routines’ Boolean and what TEClick grabs will be “who knows what” and your program should crash. SetClikLoop will install a glue routine that calls MyClikLoop. The glue routine will move the result from the stack to D0. By the way, this information is documented on pages 237–238 of Volume Two of Macintosh Revealed, Second Edition, by Stephen Chernicoff.
Now why is your program causing problems when you use SetClikLoop? You might have declared your MyClikLoop as a C function. Since MyClikLoop takes no parameters, nothing is put on the stack. But C, unlike Pascal, places its return value in D0. So, for C, the glue routine is not needed. On the other hand, if you use the SetClikLoop routine with a C routine, you will take the top 2 bytes off the stack and clobber D0 with the wrong answer. Thus, you might get problems.
Though the C routine may work by setting it directly to the clikLoop field, doing it that way is not the supported method. You should declare your MyClikLoop function as a Pascal function and use SetClikLoop.
Special handling for Control-P keyboard input in a Mac dialog
Written: 6/5/91
Last reviewed: 8/1/91
Under System 6, when Control-P is pressed, a DLE character (hex 10) appears in a Macintosh dialog’s editText field. Under System 7, pressing Control-P produces no change in the editText box. The character is fed in via a normal (unaltered) keyDown event fed to DialogSelect. Does Control-P have some special meaning to DialogSelect or TextEdit now?
___
Believe it or not, and it took several of us scratching our heads to figure this out; yes, it does, and this is by design! What you are running into is the Dialog Manager and TextEdit working together to make Cut, Copy, and Paste function keys work on an extended keyboard. The function keys on the top of an extended keyboard return $10 as their ASCII keycode. Thus, when TEKey detects that it is being called from dialog select, and the key you pass is a $10, it then looks for the event record on the stack and gets the raw keycode to determine which edit operation to perform. The bottom line is that it will not then enter the $10 in the edit field.
There is a simple workaround, and that is to install a filter proc in your dialog that detects keystrokes (actually it could always just look for this certain keystroke) and passes them to TEKey itself, thus skirting the whole issue.
Dimming and disabling a specific TEditText object
Written: 8/8/91
Last reviewed: 8/13/91
How can I dim and disable a specific TEditText object in my TDialogView so the field is not editable?
___
The trick is to use the TView methods Dimstate and ViewEnable to disable and dim the TEditText Views, and then do a TEditText.StopEdit (which disables editing in the TEditText box), and in the other case enable dimming and the view itself and use the TEditText.StartEdit (which enables editing in the TEditText box), as shown in the C++ example below:
MacApp sample code using this technique is included with DTS’s Snippets files.
Get TEHandle from DialogPeek, not GetDItem
Written: 1/17/92
Last reviewed: 2/17/92
I want to show all characters in my Macintosh control panel as bullets where the password is typed in. I cannot get the TECustomHook to work properly, it crashes before it gets to my hook routine. In the following Think C example, CPtr is dereferenced from the handle used in the control panel’s cdevValue field:
GetDItem does NOT return a TEHandle; it returns a handle to the current text of the edit item. You must get TEHandle from DialogPeek and must always monitor and change the TECustomHook on the fly. There is only one TEHandle for a dialog, no matter how many edit items are associated with the dialog. See the description of the DialogRecord data type in Inside Macintosh.
Cursor flicker while using Macintosh TextEditWritten: 5/6/92
Last reviewed: 9/15/92
The cursor flashes when the user types in TextEdit fields in my Macintosh application. This is done in TEKey. I notice that most programs hide the cursor once a key is pressed. I don’t care for this because then I have to move the mouse to see where I am. Is this a typical fix for this problem and an accepted practice?
___
There’s very little you can do to avoid this. The problem is that every time you draw anything to the screen, if the cursor’s position intersects the rectangle of the drawing being done, QuickDraw hides the cursor while it does the drawing, and then shows it again to keep it from affecting the image being drawn beneath it. Every time you enter a character in TextEdit, the nearby characters are redrawn. Usually this is invisible because the characters just line up on top of their old images, but if the cursor is nearby and visible, it will flicker while it’s hidden to draw the text. This is why virtually all programs call ObscureCursor when the user types. Also, most users don’t want the image of the cursor obscuring text they might be referring to, yet they don’t want to have to move it away and then move it back to make selections. Because it’s so commonplace, hiding the cursor probably won’t bother your users; in fact, they might very well prefer the cursor hidden. This, combined with the fact that there’s very little you can do to help the flickering, suggests that you should obscure the cursor while the user types.
TextEdit Technicalities
Text M.TE.TextEditTech
Revised by: Mary Burke April 1990
Written by: Mary Burke February 1990
This Technical Note discusses some areas in TextEdit that have not previously been clearly documented.
Changes since February 1990: Added a note about the changes in TextEdit for System Software 6.0.5, documented the low-memory global TESysJust, clarified information about text direction and _TESetJust, discussed problems with the SetWordBreak routine along with a solution to work around it, and described the differences in dialog text item behavior.
TextEdit in 6.0.5
In addition to all the features of earlier versions, TextEdit 3.0 now allows you to take advantage of the Script Manager’s handling of systems with more than one script system installed. TextEdit uses the Script Manager to support such systems and now exhibits the correct behavior for editing and displaying text in multiple styles and different scripts. Multiple scripts can even exist on a single line due to TextEdit’s use of the Script Manager. The new version of TextEdit in 6.0.5:
• handles mixed-directional text
• synchronizes keyboards and fonts
• handles double-byte characters
• determines word boundaries and line breaks
• provides outline highlighting in the background
• buffers text for performance improvements
• permits left justification in right-to-left directional scripts
• customizes word breaking
• customizes measuring
Refer to the TextEdit chapter in Inside Macintosh, Volume VI, for detailed documentation on TextEdit 3.0.
The LineStarts Array and nLines
The LineStarts array is a field in a TextEdit record that contains the offset position of the first character of each line. This array has the following boundary conditions:
• It is a zero-based array.
• The last entry in the array must have the same value as teLength.
• The maximum number of entries is 16,000.
To determine the length of a line you can use the information contained in the lineStarts array and nLines. For example, if you want to determine the length of line n, subtract the value contained in entry n of the array from the value in the entry (n+1):
The terminating condition for this measurement is when n = nLines + 1. It is important not to change the information contained in the array.
TESysJust
TESysJust is a low-memory global that specifies the system justification. The default value of this global is normally based on the system script. It is -1 when a system’s default line direction is right to left, and 0 for a default left-to-right line direction. Applications may change the value using the Script Manager routine SetSysJust; however, these applications should save the current value before using it and restore it before exiting the application or processing a MultiFinder suspend event. The current value may be obtained using the Script Manager routine GetSysJust.
Forcing Text Direction
The original TextEdit documentation introduced _TESetJust with three possible choices for justification: teJustLeft (0), teJustCenter (1), and teJustRight (-1). These choices are appropriate for script systems that are read from left to right. However, in script systems that are read from right to left, text is incorrectly displayed as left justified in dialog boxes and in other areas of applications where users cannot explicitly set the justification. To fix this problem, the behavior of teJustLeft has changed to match the line direction of the system in use, which is the value stored in TESysJust. Another constant has been added to allow an application to force left justification: teForceLeft (-2). This constant has been available for some time, but it has not been documented until now. If your application does not allow the user to change the justification, then it should use teJustLeft; if it does, then it should use teForceLeft for left justification.
A Little More on Redraw in _TESetStyle
If the redraw parameter used in _TESetStyle is FALSE, line breaks, line heights, and line ascents are not recalculated. Therefore a succeeding call to a routine using any of this information does not reflect the new style information. For example, a call to _TEGetHeight (which returns a total height between two specified lines) uses the line height set previous to the _TESetStyle call. A call to _TECalText is necessary to update this information. If redraw is TRUE, the current style information is reflected. This behavior also holds for the redraw parameter in _TEReplaceStyle.
TEDispatchRec
There is currently space reserved for four documented hooks in the TEDispatchRec: TEEolHook, TEWidthHook, TEDrawHook and TEHitTestHook. The space beyond these hooks is reserved, and any attempt to use this private area results in corrupted TextEdit data.
Custom Word Breaks
A problem exists in one of TextEdit’s advanced procedures, SetWordBreak. The current glue code does not preserve the state of the registers correctly; however, the solution is fairly simple. Instead of calling SetWordBreak and passing a pointer to your custom word break routine, pass the pointer to your external glue which should call your custom word break routine. Following is the glue code that correctly handles the registers:
WordBreakProc PROC EXPORT
IMPORT MYWORDBREAK ;Must be uppercase here
MOVEM.L D1-D2/A1,-(SP)
CLR.W -(SP) ;Space for result
MOVE.L A0,-(SP) ;Move the ptr to stack
MOVE.W D0,-(SP) ;Move the charpos to Stack
JSR MYWORDBREAK
MOVE.W (SP)+,D0 ;Set Z bit
MOVEM.L (SP)+,D1-D2/A1
RTS
ENDP
An external declaration is also necessary:
FUNCTION WordBreakProc( text: Ptr; charPos: INTEGER ) : BOOLEAN; EXTERNAL;
as is the function itself. One thing that should be noted is that it is not really necessary to have MyWordBreak boolean, but rather to have the Z bit set properly. The result of the function should be zero when you do not want a break; otherwise, a non-zero value indicates a break is desired.
FUNCTION MyWordBreak( text : Ptr; charPos : INTEGER ) : INTEGER;
{ Your word break code here. }
For more information, refer to the TextEdit chapter of Inside Macintosh, Volume I-380.
Static and Editable Text
The Dialog Manager depends on TextEdit to display text in dialog boxes. For an editable text field, the Dialog Manager simply calls _TEUpdate. Before making this call, it may double the width of the rectangle to contain the text if the height of the rectangle is sufficient for only one line and the line direction specified by TESysJust is left to right. In this case, the Dialog Manager extends the rectangle on the right. Note, however, this does not occur when your line direction is right to left.
For static text items, _TextBox is used instead. When the display rectangle is not large enough. _TextBox clips the text to the size of the specified rectangle. To avoid the clipping problem, simply make the display rectangle larger. If your dialog box contains both static and editable text items, the difference in the text handling may appear inconsistent.
Further Reference:
• Inside Macintosh, Volumes I,V & VI, TextEdit
• Inside Macintosh, Volume V, The Script Manager
• Inside Macintosh, Volume I, The Dialog Manager
• M.TE.TestEditChanges
TrueType Q&As
Imaging M.QD.TrueType.Q&As
Revised by: Developer Support Center October 1992
Written by: Developer Support Center October 1990
This Technical Note contains a collection of Q&As relating to a specific topic—questions you’ve sent the Developer Support Center (DSC) along with answers from the DSC engineers. While DSC engineers have checked the Q&A content for accuracy, the Q&A Technical Notes don’t have the editing and organization of other Technical Notes. The Q&A function is to get new technical information and updates to you quickly, saving the polish for when the information migrates into reference manuals.
Q&As are now included with Technical Notes to make access to technical updates easier for you. If you have comments or suggestions about Q&A content or distribution, please let us know by sending an AppleLink to DEVFEEDBACK. Apple Partners may send technical questions about Q&A content to DEVSUPPORT for resolution.
New Q&As and Q&As revised this month are marked with a bar in the side margin.
SetPreserveGlyph and font glyph preservation
Written: 7/22/91
Last reviewed: 8/1/92
TrueType’s SetPreserveGlyph call with preserveGlyph set to “true” works as you’d expect for Times and Helvetica, but it has no effect on New York, Geneva, Monaco, or Chicago. Why does SetPreserveGlyph work this way?
___
Glyph preservation is a function of the font. It turns out that Times and Helvetica have glyphs that extend above the ascent line, thereby enabling SetPreserveGlyph to have an effect on a particular glyph. New York, Geneva, Monaco, and Chicago’s characters all fit between the ascent and descent lines, and so do not need to be compressed to fit if preserveGlyph is true. A font must have glyphs extending above or below the ascent or descent lines for SetPreserveGlyph to have an effect.
RealFont and TrueType
Written: 9/4/91
Last reviewed: 8/1/92
What is the story with RealFont and TrueType? I am finding that, of the standard System 7 fonts, only Symbol and Courier get a TRUE for 7 point.
___
You are absolutely correct with your observation of RealFont for size 7 and certain TrueType fonts. The explanation is hidden in “The TrueType Font Format Specification” (APDA M0825LL/A), page 227:
The “head” FontHeader table contains a field “lowestRecPPEM,” which indicates the “lowest recommended pixel number per Em,” or, in other words, the “smallest readable size in pixels.” As it turns out, the Font Manager in its wisdom uses this information for the value it returns from RealFont. Note that for higher resolution devices, a point size of 7 does *not* correspond to 7 pixels; but as the unit “point” is 1/72 inch, and the screen resolution is (approximately) 72 dpi, the result corresponds to reality in this case.
The value for lowestRecPPEM can be arbitrarily set by the Font designer. We all know that small point sizes on low-resolution devices never look “great,” and even less so for outline fonts. Courier and Symbol have lowestRecPPEM = 6, while the other outline fonts in the System have lowestRecPPEM = 9. This doesn’t really mean that Courier and Symbol in size 7 (TrueType) look better than Times or Helvetica under the same conditions. It means the font designer had higher standards (or was in a different mood) when he choose lowestRecPPEM = 9.
Where to find OutlineAccessLib
Written: 12/9/91
Last reviewed: 8/1/92
Is the OutlineAccessLib library, which will provide standardized access routines to TrueType font outline bezier data, available yet? I have been unable to find this in the last few Developer CDs or the MPW 3.2 C release CD.
___
The OutlineAccessLib is now available (although somewhat disguised and hidden) on the Developer CD Vol. X (and later); it is included in the code accompanying the article “Curves ahead” in issue #8 of develop.
SetOutlinePreferred affects only calling application
Written: 3/9/92
Last reviewed: 8/1/92
Is the property that is managed by SetOutlinePreferred and GetOutlinePreferred kept on an application-by-application basis? In other words, will calling SetOutlinePreferred affect only my application? As the current value of outlinePreferred is saved in a PICT, will playing a PICT affect the playing application’s current outlinePreferred setting? I assume that outlinePreferred is not an attribute of a GrafPort; is this true?
___
The outlinePreferred setting is stored as a low-memory global value for your application. It is saved and restored during context switches, so it only effects your application and no one else’s.
DrawPicture should not alter the state of the global for you. While DrawPicture internally may set or reset this value, it’s supposed to put it back the way it found it when it is done. So, playing a PICT will not affect the current application’s outline settings.
And no, OutlinePreferred is not part of a grafport (as mentioned above.)
QuickDraw doesn’t draw ASCII 32 ($20) character
Written: 3/18/92
Last reviewed: 8/1/92
My TrueType font has all 256 characters defined with a unique glyph. I have been unable to draw the $20 (space) character. DrawChar, DrawText, DrawString and DrawJust all ignore this character in the font and draw a blank character. How can I draw it?
___
Unfortunately, the problem with the space character not being drawn is hard-coded into the text-drawing routine in the core of QuickDraw. ASCII 32 is always “optimized away,” regardless of the font being used, regardless of the particular circumstances. The only workaround is to put the corresponding character elsewhere in the ASCII character encoding (or, if this is not possible, to use an additional font).
You are lucky that TrueType fonts always render the ASCII code 13 (carriage return) if it has a glyph in the font; for bitmap fonts, if the character drawing happens with scaling, or with foreground/background colors different from black/white, even the CHR(13) drawing has been optimized away.
How to Construct Word-Break Tables
Text M.TE.WordBreakTables
Revised by: March 1988
Written by: Mark Davis November 1987
This technical note describes how to construct auxiliary break tables for use with the FindWord routine in the Script Manager.
Constructing break tables
The FindWord algorithm finds word boundaries by determining where words should not be broken. For example, “re-do” is one word: it should not be broken at the hyphen. In other words, a sequence of the form: (letter, hyphen, letter) should not be broken between the first and second or second and third character. This is called a continuation sequence. The algorithm used by the FindWord routine allows for continuation sequences of lengths one, two and three. Examples of a sequence of length two include (letter, letter), or (number, number). For a length of one, there is only one sequence, consisting of the characters of type nonBreaking: these characters are never separated from preceding or following characters.
For most scripts, this information about continuation sequences is packed into a table for use by the FindWord algorithm. (For complex scripts like Japanese, a different algorithm is used for portions of the script.) The default break tables for a given script can be overridden by a user-specified breakTable parameter, but should only be used for known scripts. That is, before overriding the breakTable parameter, the programmer should first check the script of the current font.
A break table consists of two sections, a 256 byte character type table followed by a character triple table.
The character type table is indexed by the character’s ASCII code and contains one type value for each character. The character types in the table are limited to values between 1 and 31. There are two distinguishing values: the type nonBreaking (= 1) indicates that the character is non-breaking; it always continues a word. The type wild (=0) indicates that the character may or may not break, depending on information in the character triple table, as described below. Otherwise, the choice of numbers to represent character types is completely arbitrary.
For example, the following in MPW Assembler defines character types for use in a word-selection break table, then sets up a character type table using an assembly macro (setByte) to store character type values in an array. (Note that the character types could have been defined with equate definitions (EQU), rather than using the record structure.) Writing the setByte macro is left as an exercise to the reader. Note that the break value is the default. This value is not distinguished, but should have no continuation sequences.
The character triple table is a coded representation of a list of continuation sequences. It consists of a list of packed one word triples, preceded by a length word. This length word contains the number of triples minus one. Each triple contains three character types, either as derived from the charType table or the special type wild (= zero). The three types in a triple are packed into fields five bits apiece, with the most significant bit in the word cleared. The first type in the triple is the leftmost.
A continuation sequence of length three (xyz) is represented by entering three triples into the triple list: xyz, *xy, and yz* (where ‘*’ stands for the type wild, which is always zero).
A continuation sequence of length two (xy) is represented by entering two triples into this list: *xy, and xy*. A continuation sequence of length one has no entry in the triple list: the character type is simply nonBreaking.
Note that the type wild cannot appear as the middle element of a triple. The words in the triple table must be sorted in ascending numerical order for future compatibility.
The following is an example of how a character triple table could be coded. The defSeq macro takes a continuation sequence as a parameter, and enters a set of triples into an internal array. The dumpSeq macro sorts the triples, and stores them in the proper order with dc.w commands. Once again, writing the macros defSeq and dumpSeq is left as an exercise for the reader.
A series of blanks should generally select as a single word. Make certain, however, that a carriage return does not continue a word to the right (note how it has a separate character type from blank for this reason), otherwise word selection and wrapping do not work properly across paragraphs.
Extensions
The values 16-31 in the character type table entry for null ($00) (the first byte in the character type table) are reserved by Apple for future expansion. The use of one of these values indicates the presence of a supplementary table after the triple table.
Further Reference:
• The Script Manager
Ï ◊# ˇ ˇˇˇˇ # ◊ † Ç
/ Z Å#
0Ià:µú9 " { ˇˇˇˇˇˇˇˇ # † ƒ ° d
ONLN f ˛ † å ° d 1drw2 … -·_ Ä ˇˇˇˇˇˇ è ° ñ x ° d drw2 : ° d drw2 : $ ° d 4drw2 : ° ö ˇ˙ ó@ † ò , Times
. R… R… +]BNew Technical Notes † ô ° d drw2 : °„ † ó ° d 1drw2 eÙ Ä ˇˇˇˇˇˇ P ° ñ x ° d drw2 : ° d drw2 : $ ° d 4drw2 : ° ö ˇ˚Ä E¿ † ò
( {ïDeveloper Support † ô ° d drw2 : °„ † ó ° d `drw2 - Ô ˇˇˇˇˇˇ K Ô - Z f f Z ° d 1drw2 ¿˙È ˇˇˇˇˇˇ K ° ñ x ° d drw2 : ° d drw2 : $ ° d 4drw2 : 0 ° ö ˇÙ Ä † ò
0 ( UÔ † ô ° d drw2 : °„ † ó ° d 1drw2 ÔÊ˙ ˇˇˇˇˇˇ ° ñ x ° d drw2 : ° d drw2 : $ ° d 4drw2 : ° ö ˇ˝Ä † ò
+& ® † ô ° d drw2 : °„ † ó ° d 1drw2  -¯ y ˇˇˇˇˇˇ ° ñ x ° d drw2 : ° d drw2 : $ ° d 4drw2 : ° ö ˇ˚Ä % † ò
( Z \ Macintosh † ô ° d drw2 : °„ † ó † ç ° d drw2 D † É
IR . ° d ONLN d z < ç ( ß ZThe Appearance of Text
° d ONLN d å < õ Z *Text ° d ONLN d åÜ õ˛ ( ∑§M.TE.Appearance
° d ONLN d - ß < ≥ t ( œ Z Revised by: ° d ONLN d : ß≈ ≥˛ ( œ„
March 1988 ° d ONLN d E ≥ < ø q ( € Z Written by: ° d ONLN d Q ≥ Ñ ø – )HGinger Jernigan ° d ONLN d a ≥± ø˛ ( €œ
November 1986 ° d ONLN d o À < ◊ Ä ( Û ZThis technical ° d ONLN d ~ À Ä ◊˛ )DKnote describes why text doesn’t always look the way you expect depending on ° d ONLN d ◊ < „ æ ( ˇ Zthe environment you are in. X ° d ONLN d Ê ¸ < ¿ *%There are a number of ° d ONLN d ¸ ¸ ¿˛ )Ñ=Macintosh text editing applications where layout is critical. ° d ONLN d; < – (0 Z Unfortunately, text on a newer ° d ONLN dZ –˛ )î;machine sometimes prints differently than text on a 64K ROM ° d ONLN dñ < í (< ZDMacintosh. Let’s examine some differences you should expect and why. ° d ONLN d€, <8É *BThe differences we will consider here are only differences in the ° d ONLN d ,É8˛ (T°layout of text lines (line ° d ONLN d88 <DG (` Z;layout), not differences in the appearance of fonts or the ° d ONLN ds8GD˛ (`e'differences between different printers. ° d ONLN dõD <P ˙ (l Z*Differences in line layout may affect the ° d ONLN d≈D ˙P˛ )æ5position of line, paragraph and page breaks. The four ° d ONLN d˚P <\r (x ZEvariables that can affect line layout are fonts, the printer driver, ° d ONLN d@Pr\˛ (xêthe font manager mode, and ° d ONLN d[\ <h _ (Ñ ZROMs.
° d ONLN daÄ <è ` *'Fonts
° d ONLN dgõ <ß à *Every font on a ° d ONLN dwõ à߲ )LIMacintosh contains its own table of widths which tells QuickDraw how wide ° d ONLN d¡ß <≥ ë (œ Zcharacters are on ° d ONLN d”ß ë≥˛ )UJthe screen. For every style point size there is a separate table which may ° d ONLN d ≥ <ø Ñ (€ Zcontain widths ° d ONLN d-≥ Ñø˛ )HOthat vary from face to face and from point size to point size. Character widths ° d ONLN d}ø <À (Á Z0can vary between point sizes of characters even ° d ONLN d≠ø À˛ )‚.in the same face. In other words, fonts on the ° d ONLN d‹À <◊ (Û Z-screen are not necessarily linearly scalable. ° d ONLN d
*QThe Appearance of Text (Ï1 ) of 3 ˇ ° ¿Ù%%DSIDICT:_cv
currentdict /bu known {bu}if
userdict /_cv known not{userdict /_cv 30 dict put}if
_cv begin
/bdf{bind def}bind def
currentscreen/cs exch def/ca exch def/cf exch def
/setcmykcolor where{/setcmykcolor get /cvcmyk exch def}{/cvcmyk{1 sub 4 1 roll 3{3 index add neg dup 0 lt{pop 0}if 3 1 roll}repeat setrgbcolor pop}bdf }ifelse
/ss{//cf //ca //cs setscreen}bdf
/stg{ss setgray}bdf
/strgb{ss setrgbcolor}bdf
/stcmyk{ss cvcmyk}bdf
/min1{dup 0 eq{pop 1}if}bdf
end
currentdict /bn known {bn}if
† ø ◊# ˇ ˇˇˇˇ # ◊
IR , Times
. +6-Macintosh Technical Notes / 4 /˘
° d ONLN d ) 8 ò *'The Printer Driver
° d ONLN d D P */Even when the printer you are using has a much ° d ONLN d B D P⁄ )*higher resolution than what the screen can ° d ONLN d m P \¬ ( x 6\show, printer drivers perform line layout to match the screen layout as closely as possible. ° d ONLN d h tØ *TThe line layout performed by printer drivers is limited to single lines of text and ° d ONLN d hØ t⁄ ( êÕdoes not ° d ONLN d' t Ä ( ú 63change line break positions within multiple lines. ° d ONLN dZ t Ä⁄ )Í-The driver supplies metric information to the ° d ONLN dà Ä å æ ( ® 6$application about the page size and ° d ONLN d¨ Ä æ å⁄ )¶=printable area to allow the application to determine the best ° d ONLN dÍ å ò ø ( ¥ 6#place to make line and page breaks. ° d ONLN d § ∞ ¸ *,Printer driver line layout does affect word ° d ONLN d: § ¸ ∞⁄ )‰(spacing, character spacing and even word ° d ONLN dc ∞ º ( ÿ 67positioning within a line. This may affect the overall ° d ONLN dö ∞ º⁄ )˘*appearance of text, particularly when font ° d ONLN d≈ º » ∑ ( ‰ 6"substitutions are made or various ° d ONLN dÁ º ∑ »⁄ )ü=forms of page or text scaling are involved. But print drivers ° d ONLN d% » ‘ ˙ ( 6+NEVER change line, paragraph or page break ° d ONLN dP » ˙ ‘⁄ )‚-positions from what the application or screen ° d ONLN d~ ‘ ‡ Ç ( ¸ 6specified. This means ° d ONLN dî ‘ Ç ‡⁄ )jGthat where line breaks appear on the screen, they will always appear in ° d ONLN d‹ ‡ Ïr ( 6Kthe same place on the printer regardless of how the line layout may affect ° d ONLN d' ‡r Ï⁄ (êthe appearance within ° d ONLN d= Ï ¯ > ( 6 the line.
° d ONLN dG ÷ *'Operating System and ROMs
° d ONLN da+ 7 *4In this context, operating system refers to the ROM ° d ONLN dï+ 7⁄ (S=$trap routines which handle fonts and ° d ONLN d∫7 C Δ (_ 6!QuickDraw. Changes have occurred ° d ONLN d€7 ΔC⁄ )Æ7between the ROMs in the handling of fonts. Fonts in the ° d ONLN dC OI (k 6964K ROMs contain width tables (as described above) which ° d ONLN dLCIO⁄ (kg are limited to integer values. ° d ONLN dkO [1 (w 66Several new tables, however, have been added to fonts ° d ONLN d°O1[⁄ (wO for the newer ROMs. The newer ° d ONLN dø[ gÇ (É 6MROMs add an optional global width table containing fractional or fixed point ° d ONLN d [Çg⁄ (Ɇdecimal values. In ° d ONLN d g sv (è 6Maddition, there is another optional table containing fractional values which ° d ONLN dlgvs⁄ (èîcan be scaled for the ° d ONLN dÇs π (õ 6$entire range of point sizes for any ° d ONLN d¶s π⁄ )°<one face. There is also an optional table which provides for ° d ONLN d„ ã « (ß 6&the addition (or removal) of width to ° d ONLN d «ã⁄ )Ø9a font when its style is changed to another value such as ° d ONLN dCã ó ° (≥ 6 bold, outline or condensed. ° d ONLN d_ã °ó⁄ )â=It is also possible, under the 128K ROMs, to add fonts to the ° d ONLN dùó £á (ø 6Msystem with inherent style properties containing their own width tables that ° d ONLN dÍóá£⁄ (ø•produce different ° d ONLN d¸£ Ø Â (À 6+character widths from derived style widths. ° d ONLN d(ª « g *One or all of the ° d ONLN d:ª g«⁄ )OKabove tables may or may not be invoked depending on, first, their presence, ° d ONLN dÜ« ” Ç (Ô 6and second, the mode ° d ONLN dõ« Ç”⁄ )jBof the operating system. The Font Manager in the newer ROMs allows ° d ONLN dfi” fl k (˚ 6the application to ° d ONLN dÒ” kfl⁄ )SNarbitrarily operate in either the fractional mode or integer mode (determined, ° d ONLN d @‡ Ï † ( 6 in most cases, by the setting ° d ONLN d ^‡ †Ï Æ )àof ,
Courier ° d ONLN d afl ÆÎ ˚ ) FractEnable ° d ONLN d l‡ ˚Ï⁄ )M0) as it chooses, with the default being integer. ° d ONLN d ùÏ ¯¿ ( 6\There is one case where fractional widths will be used if they exist even though fractional ° d ONLN d ˘Ï¿¯⁄ (fimode ° d ONLN d ˛˘ s (! 6is disabled. When ° d ONLN d
¯ s Œ )[
FScaleDisable ° d ONLN d
˘ Œ^ )[ is used fractional widths are ° d ONLN d
<˘^⁄ )êalways used if they exist ° d ONLN d
V ò (. 6 regardless of the setting of ° d ONLN d
s ò Â )Ä FractEnable ° d ONLN d
~ Â È )M. ° d ONLN d
Ä * Δ (F 6%Differences in line layout (and thus ° d ONLN d
• Δ*⁄ )Æ6line breaks) may be affected by any combination of the ° d ONLN d
‹* 6 ˆ (R 60presence or absence of the optional tables, and ° d ONLN d * ˆ6⁄ )fi1the operating mode, either fractional or integer, ° d ONLN d >6 B¢ (^ 6Oof the application. Any of the combinations can produce different results from ° d ONLN d ç6¢B⁄ (^¿ the original ° d ONLN d öB N § (j 6ROMs (and from each other). ° d ONLN d ∂Z fà *TThe integer mode on the newer ROMs is very similar to, but not exactly the same as, ° d ONLN d
ZÃf⁄ (ÇÍthe ° d ONLN d f rv (é 6Horiginal 64K ROMs. When fonts with the optional tables present are used ° d ONLN d Vfvr⁄ (éîon Macintoshes with ° d ONLN d jr ~y (ö 6H64K ROMs, they continue to work in the old way with the integer widths. ° d ONLN d ≤ry~⁄ (öóHowever, on newer ° d ONLN d ƒ~ äà (¶ 6[ROMs, even in the integer mode, there may be variations in line width from what is seen on ° d ONLN d
~Ãä⁄ (¶Íthe ° d ONLN d
#ä ñ (≤ 6:old ROMs. In the plain text style there is very little if ° d ONLN d
]äñ⁄ )˚*any difference (except if the global width ◊ 4◊˘
(Ï 62 ) of 3 (ÏôThe Appearance of Text ˇ^ ◊# ˇ ˇˇˇˇ # ◊
IR , Times
. +Z-Developer Support Center ( -Ï
March 1988 / X /
° d ONLN d < )á ( E ZHtable is present), but as various type styles are selected, line widths ° d ONLN d H á )˛ ( E•may vary more between ° d ONLN d ^ ) < 5 _ ( Q ZROMs. ° d ONLN d d A < M å *Variations in the ° d ONLN d v A å M˛ )PNabove options, by far, account for the greatest variation in the appearance of ° d ONLN d ≈ M < Y4 ( u Z1lines when a document is transported between one ° d ONLN d ˆ M4 Y˛ )¯&Macintosh and another. Line breaks may ° d ONLN d Y < e ‰ ( Å Z change position when documents ° d ONLN d< Y ‰ e˛ )®4created on one system (say a Macintosh) are moved to ° d ONLN dq e < q ( ç Z(another system (like a Macintosh Plus). ° d ONLN dô e q˛ )ƒ0Variations are more pronounced as the number and ° d ONLN d q < }B ( ô Z8sizes of various type styles increase within a document. ° d ONLN d â < ï I *In ° d ONLN d â I ï˛ )
[all cases, however, a printer driver will produce exactly the same line breaks as appear on ° d ONLN db ï < ° ( Ω Z-the screen with any given system combination. ° d ONLN dê ≈ < — ¶ *0Further Reference: X ° d ONLN d£ “ N fi R +
• ° d ONLN d• “ ` fi « )The Printing Manager ° d ONLN d∫ fi N Í R ( l• ° d ONLN dº fi ` Í ∑ )The Font Manager ° d ONLN dÕ Í N ˆ R ( l• ° d ONLN dœ Í ` ˆ … )M.IM.LaserWriterOpt ◊ X◊
(Ï ZThe Appearance of Text (Ï3 ) of 3 ˇ‚ ◊# ˇ ˇˇˇˇ # ◊ ° d WORD S † å ° d WORD R… † Ç
/ Z Å#
0Ià:µú9 " { ˇˇˇˇˇˇˇˇ # † ƒ ° d
ONLN f ˛ † å ° d 1drw2 … -·_ Ä ˇˇˇˇˇˇ è ° ñ x ° d drw2 : ° d drw2 : $ ° d 4drw2 : ° ö ˇ˙ ó@ † ò , Times
. ^ tK^ tK +]BNew Technical Notes † ô ° d drw2 : °„ † ó ° d 1drw2 eÙ Ä ˇˇˇˇˇˇ P ° ñ x ° d drw2 : ° d drw2 : $ ° d 4drw2 : ° ö ˇ˚Ä E¿ † ò
Ä ( {ïDeveloper Support † ô ° d drw2 : °„ † ó ° d `drw2 - Ô ˇˇˇˇˇˇ K Ô - Z f f Z ° d 1drw2 ¿˙È ˇˇˇˇˇˇ K ° ñ x ° d drw2 : ° d drw2 : $ ° d 4drw2 : 0 ° ö ˇÙ Ä † ò
0 ( UÔ † ô ° d drw2 : °„ † ó ° d 1drw2 ÔÊ˙ ˇˇˇˇˇˇ ° ñ x ° d drw2 : ° d drw2 : $ ° d 4drw2 : ° ö ˇ˝Ä † ò
l +& ® † ô ° d drw2 : °„ † ó ° d 1drw2  -¯ y ˇˇˇˇˇˇ ° ñ x ° d drw2 : ° d drw2 : $ ° d 4drw2 : ° ö ˇ˚Ä % † ò
BÄ ( Z \ Macintosh † ô ° d drw2 : °„ † ó † ç ° d drw2 D † É ° d WORD † ç
IR . ° d ONLN d { < éû ( ® Z'Script Manager 2.0 Date & Time Problems
° d ONLN d ( ç < ú Z *Text ° d ONLN d . çk ú˛ ( ∏âM.TE.ScriptDateTime
° d ONLN d B ® < ¥ q ( – Z Written by: ° d ONLN d N ® Ñ ¥ ¡ )H John Harvey ° d ONLN d Z ®∏ ¥˛ ( –÷
February 1990 ° d ONLN d h ¿ < à T ( Ë ZThis ° d ONLN d m ¿ T Ã˛ )VTechnical Note describes known bugs and features in and solutions to the date and time ° d ONLN d ƒ à < ÿ ( Ù Z*routines introduced in Script Manager 2.0. X ° d ONLN d Ô Ò < ˝( *%/From the beginning, the Macintosh’s ability to ° d ONLN d Ò( ˝˛ )Ï*handle dates was limited to a rather small ° d ONLN dI ˝ < ı (% Z%range—slightly more than a century. ° d ONLN dn ˝ ı ˛ )π3Enhancements to the Script Manager, introduced with ° d ONLN d¢ < ê (1 ZSystem Software ° d ONLN d≤ ê˛ )TK6.0, extended this range to ±35,000 years. Unfortunately, there is a minor ° d ONLN d˛ <!ß (= ZQbug in one of the crucial calls and a “feature” that looks like a bug in another.
° d ONLN dP9 <H, *' You Said It Would Be A Long Time ,
Courier
° d ONLN dqT <` û *_LongSecs2Date ° d ONLN dU ûa% )b , the routine that translates a ° d ONLN düT%`y )á LongDateTime ° d ONLN d´Uyaê )T to a ° d ONLN d±Tê`› ) LongDateRec ° d ONLN dºU›a˛ )M, has a ° d ONLN dƒa <m Q (â Zbug ° d ONLN d»a Qm˛ )[caused by using a variable that has not been properly initialized. This bug rears its ugly ° d ONLN d$m <y (ï Z,head when negative values are passed to the ° d ONLN dPmy˛ )“2routine. System Software 6.0.4 and later fix this ° d ONLN dÉy <Ö< (° Z8bug, and there is a simple solution for earlier systems. ° d ONLN dºí <ûI *8If using System Software 6.0.3 and earlier, if you call ° d ONLN dÙëIù´ (∫g_LongSecs2Date ° d ONLN dí´û… )b once ° d ONLN dí…û˛ )
before you ° d ONLN dü <´ s (« Z really want ° d ONLN d ü s´z )7=to use it, the variable is cleared. After the initial call, ° d ONLN d\ûz™‹ («ò_LongSecs2Date ° d ONLN djü‹´˛ )b works ° d ONLN dq´ <∑ i (” Z
correctly. ° d ONLN d|√ <œ z * For example: ° d ONLN d†<Á É *
MPW Pascal
° d ONLN dîÛ <˛ ™ *PROCEDURE DoDateStuff; ° d ONLN d´˝ < K *
VAR ° d ONLN dØ < ™ *
lsecs: LongDateTime; ° d ONLN dΔ < • *
ldr: LongDateRec; ° d ONLN d‹ <& U *
BEGIN ° d ONLN d‚% <0 • *
InitDateCache(dcr); ° d ONLN d¯/ <: } *
lsecs := 0; ° d ONLN d9 <D √ *
LongSecs2Date(lsecs,ldr); ° d ONLN d"C <N *
+ {now you can call LongSecs2Date for real} ° d ONLN dNW <b P *END;
° d ONLN dSm <y h *MPW C
° d ONLN dYÖ <ê ñ *void DoDateStuff() ° d ONLN dlè <ö A *
{ ° d ONLN dnô <§ • *
LongDateTime lsecs; ° d ONLN dÑ£ <Æ õ *
LongDateRec ldr; ◊ X◊
*"'Script Manager 2.0 Date & Time Problems (Ï1 ) of 2 ˇ ° ¿Ù%%DSIDICT:_cv
currentdict /bu known {bu}if
userdict /_cv known not{userdict /_cv 30 dict put}if
_cv begin
/bdf{bind def}bind def
currentscreen/cs exch def/ca exch def/cf exch def
/setcmykcolor where{/setcmykcolor get /cvcmyk exch def}{/cvcmyk{1 sub 4 1 roll 3{3 index add neg dup 0 lt{pop 0}if 3 1 roll}repeat setrgbcolor pop}bdf }ifelse
/ss{//cf //ca //cs setscreen}bdf
/stg{ss setgray}bdf
/strgb{ss setrgbcolor}bdf
/stcmyk{ss cvcmyk}bdf
/min1{dup 0 eq{pop 1}if}bdf
end
currentdict /bn known {bn}if
† ø Ê ◊# ˇ ˇˇˇˇ # ◊
IR , Times
. +6-Macintosh Technical Notes / 4 /˘ ,
Courier
° d ONLN d 1 < ï *+/* work around the bug */ ° d ONLN d ; F T *
%/* now call LongSecs2Date for real */ ° d ONLN d k Y d *
}
° d ONLN d m { ä õ *&Any String To Date
° d ONLN d Ä ó £ Q * The routine ° d ONLN d å ñ Q ¢ • )9 _String2Date ° d ONLN d ò ó • £ æ )T was ° d ONLN d ù ó æ £⁄ )=originally designed to be as forgiving as possible. It is so ° d ONLN d € £ Øñ ( À 6Tforgiving that it accepts any non-alphabetic character as a separator and accepts a ° d ONLN d/ £ñ Ø⁄ ( À¥
single number ° d ONLN d= ∞ º Ê ( ÿ 6,as a valid date. For instance, if you pass ° d ONLN di Ø Ê ª: )Œ _String2Date ° d ONLN du ∞: º¶ )T a string like “<20” it ° d ONLN dç ∞¶ º⁄ )l
generously ° d ONLN dò º » ( ‰ 65assumes that the less than sign (<) is intended as a ° d ONLN dÕ º »⁄ )+divider and that “20” must be intended as a ° d ONLN d˘ … ’U ( Ò 6Gday, since there are only 12 months in a year. It returns a result of ° d ONLN d@ »U ‘x ( ÒsnoErr ° d ONLN dE …x ’⁄ )# and a date which is ° d ONLN dZ ’ · ( ˝ 69the twentieth of the current month in the current year. ° d ONLN dì ’ ·⁄ ( ˝7%The string “<3*3” produces March 3 of ° d ONLN dπ · Ìå ( 6Rthe current year, while “4>1” politely gives the date April 1 of the current year. ° d ONLN d ˘ w *OThis forgiveness really is not a bug, but a feature. Unfortunately it isn’t a ° d ONLN d[ ˘w⁄ (!ïfeature that has been ° d ONLN dq Ö (- 6Lgreatly appreciated in the developer community. For that reason, the rules ° d ONLN dΩÖ⁄ (-£for date and time ° d ONLN dœ B (9 6 dividers ° d ONLN dÿ B ⁄ )*Tare tighter in System 7.0. Current thinking is that all list separators now used in ° d ONLN d- ) B (F 6'itl0' ° d ONLN d3 B*j )*= resources will be allowed with a few common date separators ° d ONLN dp j*⁄ (Fàused in the U.S. (e.g., ° d ONLN dà* 6% (R 6;colon (:) and hyphen (-)). For now, it is important to be ° d ONLN d√*%6⁄ (RC'aware of, shall we say, the flexibility ° d ONLN dÎ7 C % (_ 6of ° d ONLN dÓ6 %B y )
_String2Date ° d ONLN d˙7 yCs )T9 and avoid thinking of it as an intelligent date parser. ° d ONLN d37sC⁄ )˙ If you want to parse ° d ONLN dID P ã (l 6something, you can use ° d ONLN d`C ãO Ê )s
_IntlTokenize ° d ONLN dmD ÊP Í )[. ° d ONLN dot Ä Ç (ú 6Further Reference: ü 4ü˘ ° d ONLN dÇÅ *ç . +
• ° d ONLN dÑÅ <ç ç )Inside Macintosh ° d ONLN dîÅ çç( )Q , Volume V, The Script Manager ° d ONLN d≥ç *ô . (µ H• ° d ONLN dµç <ô ¨ )The Script Manager 2.0 ° d ONLN dÀç ¨ô )p, Interim Chapter (DTS) ◊ 4◊˘
(Ï 62 ) of 2 (ÏJ'Script Manager 2.0 Date & Time Problems ˇ @ ◊# ˇ ˇˇˇˇ # ◊ ° d WORD S † å ° d WORD R… † Ç
/ Z Å#
0Ià:µú9 " { ˇˇˇˇˇˇˇˇ # † ƒ ° d
ONLN f ˛ † å ° d 1drw2 … -·_ Ä ˇˇˇˇˇˇ è ° ñ x ° d drw2 : ° d drw2 : $ ° d 4drw2 : ° ö ˇ˙ ó@ † ò , Times
. eRSeRS +]BNew Technical Notes † ô ° d drw2 : °„ † ó ° d 1drw2 eÙ Ä ˇˇˇˇˇˇ P ° ñ x ° d drw2 : ° d drw2 : $ ° d 4drw2 : ° ö ˇ˚Ä E¿ † ò
Ä ( {ïDeveloper Support † ô ° d drw2 : °„ † ó ° d `drw2 - Ô ˇˇˇˇˇˇ K Ô - Z f f Z ° d 1drw2 ¿˙È ˇˇˇˇˇˇ K ° ñ x ° d drw2 : ° d drw2 : $ ° d 4drw2 : 0 ° ö ˇÙ Ä † ò
0 ( UÔ † ô ° d drw2 : °„ † ó ° d 1drw2 ÔÊ˙ ˇˇˇˇˇˇ ° ñ x ° d drw2 : ° d drw2 : $ ° d 4drw2 : ° ö ˇ˝Ä † ò
l +& ® † ô ° d drw2 : °„ † ó ° d 1drw2  -¯ y ˇˇˇˇˇˇ ° ñ x ° d drw2 : ° d drw2 : $ ° d 4drw2 : ° ö ˇ˚Ä % † ò
BÄ ( Z \ Macintosh † ô ° d drw2 : °„ † ó † ç ° d drw2 D † É ° d WORD † ç
IR . ° d ONLN d { < é§ ( ® Z)Drawing Characters into a Narrow GrafPort
° d ONLN d * ç < ú Z *Text ° d ONLN d 0 ç` ú˛ ( ∏~M.TE.TextInNarrowGP
° d ONLN d D ® < ¥ t ( – Z Revised by: ° d ONLN d Q ®≈ ¥˛ ( –„
March 1988 ° d ONLN d \ ¥ < ¿ q ( ‹ Z Written by: ° d ONLN d h ¥ Ñ ¿ – )HGinger Jernigan ° d ONLN d x ¥æ ¿˛ ( ‹‹ January 1986 Î X Î ° d ONLN d Ö ⁄ < Ê ’ ( Z When you draw a character into ° d ONLN d § ⁄ ’ Ê fi )ôa ,
Courier ° d ONLN d ¶ Ÿ fi  ) GrafPort ° d ONLN d Æ ⁄ Ê˛ )80, your program will die with an address error if ° d ONLN d fl Á < Û ç ( Zthe width of the ° d ONLN d Ê ç Ú ≈ )QGrafPort ° d ONLN d ¯ Á ≈ Û ˚ )8 is smaller ° d ONLN d Á ˚ Û˛ )64than the width of the character. If you check before ° d ONLN d9 Ù < › ( Z$drawing the character to see if the ° d ONLN d] Û › ˇ )°GrafPort ° d ONLN de Ù ˛ )8/ is wide enough, you can avoid this unfortunate ° d ONLN dï < c (( Ztragedy. ° d ONLN dû0 << ¶ *0Further Reference: [ X[ ° d ONLN d±= NI R +
• ° d ONLN d≥= `I ñ ) QuickDraw ◊ X◊
(Ï Z)Drawing Characters into a Narrow GrafPort (Ï1 ) of 1 ˇ ° ¿Ù%%DSIDICT:_cv
currentdict /bu known {bu}if
userdict /_cv known not{userdict /_cv 30 dict put}if
_cv begin
/bdf{bind def}bind def
currentscreen/cs exch def/ca exch def/cf exch def
/setcmykcolor where{/setcmykcolor get /cvcmyk exch def}{/cvcmyk{1 sub 4 1 roll 3{3 index add neg dup 0 lt{pop 0}if 3 1 roll}repeat setrgbcolor pop}bdf }ifelse
/ss{//cf //ca //cs setscreen}bdf
/stg{ss setgray}bdf
/strgb{ss setrgbcolor}bdf
/stcmyk{ss cvcmyk}bdf
/min1{dup 0 eq{pop 1}if}bdf
end
currentdict /bn known {bn}if
† øX ◊# ˇ ˇˇˇˇ # ◊ ° d WORD S † å ° d WORD R… † Ç
/ Z Å#
0Ià:µú9 " { ˇˇˇˇˇˇˇˇ # † ƒ ° d
ONLN f ˛ † å ° d 1drw2 … -·_ Ä ˇˇˇˇˇˇ è ° ñ x ° d drw2 : ° d drw2 : $ ° d 4drw2 : ° ö ˇ˙ ó@ † ò , Times
. eRSeRS +]BNew Technical Notes † ô ° d drw2 : °„ † ó ° d 1drw2 eÙ Ä ˇˇˇˇˇˇ P ° ñ x ° d drw2 : ° d drw2 : $ ° d 4drw2 : ° ö ˇ˚Ä E¿ † ò
Ä ( {ïDeveloper Support † ô ° d drw2 : °„ † ó ° d `drw2 - Ô ˇˇˇˇˇˇ K Ô - Z f f Z ° d 1drw2 ¿˙È ˇˇˇˇˇˇ K ° ñ x ° d drw2 : ° d drw2 : $ ° d 4drw2 : 0 ° ö ˇÙ Ä † ò
0 ( UÔ † ô ° d drw2 : °„ † ó ° d 1drw2 ÔÊ˙ ˇˇˇˇˇˇ ° ñ x ° d drw2 : ° d drw2 : $ ° d 4drw2 : ° ö ˇ˝Ä † ò
l +& ® † ô ° d drw2 : °„ † ó ° d 1drw2  -¯ y ˇˇˇˇˇˇ ° ñ x ° d drw2 : ° d drw2 : $ ° d 4drw2 : ° ö ˇ˚Ä % † ò
BÄ ( Z \ Macintosh † ô ° d drw2 : °„ † ó † ç ° d drw2 D † É ° d WORD † ç
IR . ° d ONLN d { < é ø ( ® Z
Fond of FONDs
° d ONLN d ç < ú Z *Text ° d ONLN d ç£ ú˛ ( ∏¡
M.TE.FONDs
° d ONLN d ® < ¥ q ( – Z Written by: ° d ONLN d + ® Ñ ¥ Ÿ )H Joseph Maurer ° d ONLN d > ®À ¥˛ ( –È May 1992 ° d ONLN d H ¿ < Ã Ω ( Ë ZThis Technical Note takes ° d ONLN d b ¿ Ω ÃF )Åthe place of Tech Note #26 ° d ONLN d | ¿F ÃK )â, ° d ONLN d } ¿K Ã˛ )$ “Character vs. String Operations in ° d ONLN d ¢ à < ÿ | ( Ù Z QuickDraw” ° d ONLN d ≠ à | ÿ˛ )@Iby Bryan Stearns (March 1988), which pointed out the possible differences ° d ONLN d ˜ ÿ < ‰¶ ( ZMbetween the results of a StringWidth call and successive calls to CharWidth. ° d ONLN dD ÿ¶ ‰˛ ( ƒThis Note updates ° d ONLN dV ‰ < # ( Z-and brings into a broader context the issues ° d ONLN dÉ ‰# ˛ )Á+related to text measuring. It also provides ° d ONLN dØ < ¸Ê ( ZSadditional documentation on font family resources ('FOND's), and addresses various ° d ONLN d Ê ¸˛ (other ° d ONLN d ¸ <B ($ Z7frequently asked questions related to the Font Manager. 3 X3
° d ONLN dA- << è *4 Introduction
° d ONLN dNH <T~ *CEvery Macintosh developer needs to draw text in a GrafPort, and to ° d ONLN dëH~T˛ (púspecify typeface, size, and ° d ONLN d≠T <` ∫ (| Z style. In most cases, there ° d ONLN d…T ∫`˙ )~Aare no problems, and application developers don’t need to have in ° d ONLN d
think. We ° d ONLN d ÌÄ nå˛ )2Pwill document the effects of SetFractEnable in more detail and mention some more ° d ONLN d
>å <ò † (¥ Zline layout problems. ◊ X◊
*8
Fond of FONDs (Ïˇ1 ) of 12 ˇ ° ¿Ù%%DSIDICT:_cv
currentdict /bu known {bu}if
userdict /_cv known not{userdict /_cv 30 dict put}if
_cv begin
/bdf{bind def}bind def
currentscreen/cs exch def/ca exch def/cf exch def
/setcmykcolor where{/setcmykcolor get /cvcmyk exch def}{/cvcmyk{1 sub 4 1 roll 3{3 index add neg dup 0 lt{pop 0}if 3 1 roll}repeat setrgbcolor pop}bdf }ifelse
/ss{//cf //ca //cs setscreen}bdf
/stg{ss setgray}bdf
/strgb{ss setrgbcolor}bdf
/stcmyk{ss cvcmyk}bdf
/min1{dup 0 eq{pop 1}if}bdf
end
currentdict /bn known {bn}if
† ø∫ ◊# ˇ ˇˇˇˇ # ◊
IR , Times
. +6-Macintosh Technical Notes / 4 /˘
° d ONLN d + w *Finally, this Note ° d ONLN d w +⁄ )_Cincludes sample code that puts the OutlineMetrics call to work, and ° d ONLN d X + 7 ( S 60determines text bounding boxes for bitmap fonts.
° d ONLN d â O ^ æ *'Some FOND Background
° d ONLN d ü j v P * Originally ( ° d ONLN d ´ j P v £ )8Inside Macintosh ° d ONLN d ª j £ v “ )S Volume ° d ONLN d √ j “ v⁄ )/5I, Chapter 7), all font-related data was contained in ° d ONLN d ˘ v Ç ( û 6,resources of type 'FONT'. For a font number ° d ONLN d% v Ç⁄ )Î*within the range 0....255, and a font size ° d ONLN dP Ç éh ( ™ 6Frestricted to less than 128, the (unnamed) 'FONT' resource with an ID: ° d ONLN dò ö < ¶ ” +$ 128*(font number) + (font size) ° d ONLN d∏ ≤ æ ∏ ( ⁄ 6"contained the bitmap font strike, ° d ONLN d⁄ ≤ ∏ æ⁄ )†6while the 'FONT' resource with ID = 128*(font number), ° d ONLN d æ Ï ( Ê 6.corresponding to font size 0, did not contain ° d ONLN d? æ Ï ⁄ )‘1any data, but its resource name provided the font ° d ONLN dq ÷∑ ( Ú 6Yfamily name. QuickDraw took care of stylistic variants like italic, bold, shadow, and so ° d ONLN d ∑ ÷⁄ ( Ú’on; if a ° d ONLN d” ÷ ‚ ( ˛ 65user had a specifically fine-tuned font strike for a ° d ONLN d ÷ ‚» )¸#stylistic variant, QuickDraw would ° d ONLN d+ ÷» ‚⁄ )¥not ° d ONLN d/ ‚ Ó Ó (
6.automatically substitute it when drawing text. ° d ONLN d^ ˙ — *(For aesthetic reasons, bitmap fonts for ° d ONLN dÜ ˙ —÷ )π5different sizes were usually designed with widths non ° d ONLN dª ˙÷⁄ ("Ù- ° d ONLN dº
(. 66proportional to the point size. For example, the text ° d ONLN dÚ
º )ı%“Show the difference in text widths” ° d ONLN dº⁄ )Ødrawn ° d ONLN d Æ (: 6Pwith Courier 9 measures 170 pixels, whereas the same text drawn with Courier 18 ° d ONLN dmÆ ⁄ (:Ãmeasures ° d ONLN dv * Î (F 6'374 pixels, which is 10% more than you ° d ONLN dù Î*⁄ )”-expect. (By the way, this is bad news for the ° d ONLN dÀ* 63 (R 6:ImageWriter printer driver. When “Best” mode (144 dpi) is ° d ONLN d*36⁄ (RQ$selected and text in Courier 9 is to ° d ONLN d*6 B (^ 62be printed, the printer driver uses Courier 18 to ° d ONLN d\6B⁄ )Î,render the 9-point font size on the paper at ° d ONLN dâB Në (j 6Ptwice the screen resolution, and obviously has big trouble compensating for the ° d ONLN dŸBëN⁄ (jØ10% difference ° d ONLN dËN Z [ (v 6in text width.) ° d ONLN d¯f r U *
On the other ° d ONLN df Ur⁄ )=Phand, given that only integer character widths (in QuickDraw’s 72 dpi units) are ° d ONLN dVr ~ F (ö 6
possible, ° d ONLN d`r F~⁄ ).Pproportional font scaling is compromised anyway. Accumulated rounding errors in ° d ONLN d±~ ä% (¶ 6:text measuring, particularly for scaled fonts, contribute ° d ONLN dÎ~%ä⁄ (¶C"to the headaches of many Macintosh ° d ONLN dä ñS (≤ 6Bprogrammers. The computed text widths (vital for positioning text ° d ONLN dPäSñ⁄ (≤q precisely and for line layout ° d ONLN dnñ ¢ [ (æ 6algorithms to ° d ONLN d|ñ [¢⁄ )CKjustify text) sometimes change quite abruptly when the user removes or adds ° d ONLN d»¢ Æ k ( 6certain font sizes. ° d ONLN d‹∫ Δ] *BThe introduction of the LaserWriter, and the success of Macintosh ° d ONLN d ∫]Δ⁄ (‚{in the desktop publishing ° d ONLN d8Δ “Ç (Ó 6Narena, required an extension of the original Font Manager architecture. This ° d ONLN dÜΔÇ“⁄ (Ó†extension is based ° d ONLN dô“ fi ® (˙ 6 on the concept of “font family ° d ONLN d∏“ ®fi⁄ )ê<description” resources of type 'FOND', and on a new resource ° d ONLN dıfi Í ÿ ( 6)type 'NFNT' for the data of the existing ° d ONLN d fi ÿÍK )¿'FONT' resources (see ° d ONLN d 4fiKÍù )sInside Macintosh ° d ONLN d DfiùÍ⁄ )R Volume IV, ° d ONLN d PÍ ˆ N ( 6 Chapter 5). ° d ONLN d \ t *BThe 'FOND' resource stores size-independent information about the ° d ONLN d ût⁄ (*ífont family, and its ° d ONLN d ≥ ª (6 6#resource ID is the font number (in ° d ONLN d ÷ ª⁄ )£8the range 0...32767). The resource name of the 'FOND' is ° d ONLN d
& ˜ (B 61the font name, and it contains a variable-length ° d ONLN d
@ ˜&p )flfont association table ° d ONLN d
Vp&w )y, ° d ONLN d
Xw&⁄ )which references the ° d ONLN d
m& 2 à (N 6font strikes belonging ° d ONLN d
Ñ& à2⁄ )pDto a specific font family. These references include size, style, and ° d ONLN d
…2 > b (Z 6resource ID of ° d ONLN d
ÿ2 b>⁄ )JGthe 'NFNT' or 'FONT' resource containing the bitmap font data. TrueType ° d ONLN d > J ˆ (f 61fonts were retrofitted into this scheme, and are ° d ONLN d Q> ˆJ⁄ )fi2identified as font strike resources for point size ° d ONLN d ÑJ Vm (r 6Lzero. Any reference to point size zero refers to a resource of type 'sfnt'. ° d ONLN d —b n 7 *Note: ° d ONLN d ◊b <n6 )$3The range 0...32767 for font numbers is subdivided ° d ONLN d
b6n∂ )˙into ranges for the various ° d ONLN d &n <z ó (ñ Zscript systems (see ° d ONLN d 9n óz Ò )[ Inside Macintosh ° d ONLN d Kn Òz )ZVolume ° d ONLN d Rnz∂ )) VI, pages 13-8 and 14-22, and ° d ONLN d pz <Ü ∫ (¢ ZM.TE.FontsAndScripts). ° d ONLN d áz ∫Ü∂ )~0This restricts the range of font numbers for the ° d ONLN d ∏Ü <íö (Æ ZHRoman script to 0...16383, with 0, 1, and 16383 reserved for the system. ◊ 4◊˘
(Ï 62 ) of 12 (Ï∑
Fond of FONDs ˇD ◊# ˇ ˇˇˇˇ # ◊
IR , Times
. +Z-Developer Support Center ( -ÛMay 1992 / X /
° d ONLN d ` ) † ( E ~ Since Apple ° d ONLN d † )⁄ )@?originally intended fonts to be referenced by their font family ° d ONLN d L ) ` 5 Ò ( Q ~numbers, DTS attempted to ° d ONLN d f ) Ò 5Ö )ë register those numbers (see ° d ONLN d Ç )Ö 5⁄ )îInside Macintosh ° d ONLN d ì 5 ` A ¨ ( ] ~Volume I, page ° d ONLN d ¢ 5 ¨ A⁄ )L:219 and Volume IV, page 31). This failed—not only because ° d ONLN d › A ` Mi ( i ~5the number of fonts registered grew greater than the ° d ONLN d Ai M⁄ ( iánumber of font family ° d ONLN d( M ` Y å ( u ~numbers ° d ONLN d0 M å Y⁄ ),Cavailable, but also because the Font/DA Mover (version 3.8, shipped ° d ONLN dt Y ` e- ( Å ~&with System 6), and the “Mover” built ° d ONLN dö Y- e⁄ )Õ into the System 7 Finder resolve ° d ONLN dª e ` q¬ ( ç ~Gconflicts between font IDs (which happened anyway!) by renumbering the ° d ONLN d e¬ q⁄ ( ç‡fonts ° d ONLN d q ` } ∏ ( ô ~on-the-fly. There ° d ONLN d q ∏ }⁄ )X7is no font ID registration any more—except for the very ° d ONLN dR } ` â ö ( • ~
special case ° d ONLN d_ } ö â⁄ ):@of Japanese Kanji 'FOND'–'fbit' IDs, and potentially for Korean, ° d ONLN d† â ` ï ( ± ~$Chinese and other double-byte fonts. ° d ONLN dΔ ° ` ≠+ *'As early as April 1988, M.IM.FontNames ° d ONLN dÌ °+ ≠⁄ )À!recommended the use of font names ° d ONLN d ≠ ` πZ ( ’ ~2rather than font family numbers. Since then, the ° d ONLN dA ≠Z π⁄ )˙recommendation has been ° d ONLN dY π ` ≈ • ( · ~reinforced in ° d ONLN dg π • ≈ ˘ )EInside Macintosh ° d ONLN dw π ˘ ≈Ç )T Volume VI, page 12-16. ° d ONLN dè πÇ ≈⁄ )âFortunately, most ° d ONLN d° ≈ ` — £ ( Ì ~
applications ° d ONLN dÆ ≈ £ —⁄ )C3have been good about following this recommendation. ° d ONLN d‚ — ` › ≠ ( ˘ ~Unfortunately, ° d ONLN dÒ — ≠ ›⁄ )M5some exceptions remain, even in Apple’s own software. ° d ONLN d' › ` È È ( ~QuickDraw Pictures created ° d ONLN dB › È È⁄ )â/without 32-Bit QuickDraw refer to fonts by font ° d ONLN dr È ` ı ¡ ( ~family number only! ° d ONLN dá <
() Z For obvious ° d ONLN dì
˛ )CIreasons of upward compatibility (to maintain existing fonts, and to avoid ° d ONLN d›
<j (5 Z>reflowing of existing documents), the introduction of 'FOND's ° d ONLN d
j˛ (5à did not solve all the problems. ° d ONLN d; <% fi (A Z$This is what this Note is all about.
° d ONLN d`= <L ù *'
Moofing Fonts
° d ONLN dnX <dˆ *VThe Font/DA Mover utility has evolved into version 4.1, which knows about 'sfnt's. It ° d ONLN dƒXˆd˛ (Äis ° d ONLN d«d <p à (å Zavailable on the ° d ONLN dÿd àp À )L Developer CD ° d ONLN d‰d Àp Œ )C ° d ONLN dÂd Œp Î )Series ° d ONLN dÎd Îp∑ ) * disc, path “Tools & Apps (Moof!): Misc. ° d ONLN dd∑p˛ )ÃUtilities:”. The ° d ONLN d&p <|G (ò Z5Finder in System 7 incorporates its own “Mover” (see ° d ONLN d[pG|ô (òeInside Macintosh ° d ONLN dkpô|Ù )R Volume VI, page ° d ONLN d|pÙ|˙ )[9 ° d ONLN d}p˙|˛ )- ° d ONLN d~| <àÇ (§ Z@33), which makes the Font/DA Mover redundant for System 7 users. ° d ONLN døî <†z *?Given the combinatorial explosion of all imaginable situations ° d ONLN d˛îz†˛ (ºòwith 'FOND's, 'FONT's, ° d ONLN d† <¨î (» ZH'NFNT's and 'sfnt's, and stylistic variations of fonts belonging to the ° d ONLN d]†î¨˛ (»≤same family, the font ° d ONLN ds¨ <∏+ (‘ Z1moving job deserves respect. The following notes ° d ONLN d§¨+∏˛ )Ô*cover some less well-known aspects of this ° d ONLN dœ∏ <ƒ i (‡ Z business. ° d ONLN dŸ— N› R +• ° d ONLN d€— [› Õ )
If an old “standalone” ,
Courier ° d ONLN dÚ– Õ‹ ˜ )r'FONT' ° d ONLN d¯— ˜›r )* (without corresponding ° d ONLN d–r‹ú ){'FOND' ° d ONLN d—ú›“ )* resource) ° d ONLN d!—“›⁄ )6is ° d ONLN d$› [Èä ( y:moved into a suitcase file, Font/DA Mover or the System 7 ° d ONLN d^›äÈ⁄ (®Mover creates a ° d ONLN dnÍ [ˆ Ñ ( yminimal ° d ONLN dvÈ Ñı Æ ))'FOND' ° d ONLN d|Í Æˆ* )* resource on-the-fly. This ° d ONLN dóÈ*ıT )|'FOND' ° d ONLN dùÍTˆœ )* has no tables, and nearly ° d ONLN d∏Íœˆ⁄ ){all ° d ONLN dºˆ [ i ( yits ° d ONLN d¿ˆ i⁄ )Kfields are zeroed. The System 7 Finder also converts the resource type from ° d ONLN d [ Ö (+ y'FONT' ° d ONLN d Ö î )* to ° d ONLN d î æ )'NFNT' ° d ONLN d æΔ )*7; unfortunately, the Font/DA Mover keeps the resource ° d ONLN d SΔ⁄ (+‰type ° d ONLN d X [ Ö (8 y'FONT' ° d ONLN d ^ Ö â )*. ° d ONLN d `( <4 [ (P ZNote: ° d ONLN d f( `4 ‚ )$ While it is perfectly legal ° d ONLN d Ç( ‚4⁄ )Ç/to have 'FOND's continue to reference the older ° d ONLN d ≤4 `@ ˝ (\ ~ 'FONT' type, DTS recommends ° d ONLN d Œ4 ˝@⁄ )ù)that you avoid 'FONT's. Accessing 'FONT's ° d ONLN d ¯@ `L Í (h ~is much slower, since the ° d ONLN d
@ ÍL⁄ )ä)Font Manager always looks for 'FOND's and ° d ONLN d
<L `X Δ (t ~'NFNT's first. More ° d ONLN d
PL ΔX⁄ )f8importantly, 'FONT's are troublemakers if an application ° d ONLN d
âX `dP (Ä ~.comes with its own font in its resource fork. ° d ONLN d
∑XPd⁄ )Imagine an application that ° d ONLN d
”d `pµ (å ~Dincludes a private 'FOND' which references a 'FONT' in its resource ° d ONLN d dµp⁄ (å”fork by ° d ONLN d p `|9 (ò ~)resource ID. When the Font Manager wants ° d ONLN d Hp9|⁄ )Ÿ#to load the font resource, it first ° d ONLN d l| `à é (§ ~
looks for ° d ONLN d v| éà⁄ ).Ca resource of type 'NFNT' with this same resource ID. If there’s an ° d ONLN d ∫à `îl (∞ ~5'NFNT' in the System file with the same resource ID, ° d ONLN d Ôàlî⁄ (∞äthe Font Manager will ° d ONLN d î `†ü (º ~>pick it instead of the 'FONT' from the application’s resource ° d ONLN d Cîü†⁄ (ºΩ fork. This ° d ONLN d O† `¨2 (» ~,happens more often than you’d like to think! ◊ X◊
(Ï Z
Fond of FONDs (Ïˇ3 ) of 12 ˇfi ◊# ˇ ˇˇˇˇ # ◊
IR , Times
. +6-Macintosh Technical Notes / 4 /˘
° d ONLN d + * 7 . +&• ° d ONLN d + 7 7 Â )
%Under the current font architecture, ° d ONLN d ' + Â 7∂ )Æ)the font name is the resource name of the ,
Courier ° d ONLN d Q 7 7 C a ( ` U'FOND' ° d ONLN d W 8 a D Ê )* resource (let’s forget about ° d ONLN d u 7 Ê C )Ö'FONT' ° d ONLN d { 8 DQ )*s altogether), ° d ONLN d ä 8Q D∂ )Aso the font name can ° d ONLN d ü D 7 Pä ( l UJbe any Pascal string. Unfortunately, this conflicts with the 31-character ° d ONLN d È Dä P∂ ( l®
limitation ° d ONLN d Ù P 7 \ ( x U0of a file name when the System 7 Finder derives ° d ONLN d$ P \∂ )Á the file name of a movable font ° d ONLN dD \ 7 h I ( Ñ Ufile ° d ONLN dI \ I h M )( ° d ONLN dJ \ M h ü )Inside Macintosh ° d ONLN dZ \ ü h≤ )R5 Volume VI, page 9-34) from the font name. Some third ° d ONLN dè \≤ h∂ ( Ñ–- ° d ONLN dê h 7 t â ( ê Uparty fonts come ° d ONLN d° h â t∂ )R;with font names long enough to cause trouble. You may also ° d ONLN d› t 7 Ä ( ú U'see this problem when trying to open a ° d ONLN d t Ä∂ ) %suitcase if the Finder can't generate ° d ONLN d* Ä 7 å Ú ( ® U+distinct names for all of the fonts in the ° d ONLN dU Ä Ú å∂ )ª)suitcase; the Finder may say the suitcase ° d ONLN d å 7 ò Ω ( ¥ U is “damaged” when it is not. ° d ONLN dú § ∞ 7 ( à 6Note: ° d ONLN d¢ § < ∞f )$;Each TrueType 'sfnt' resource contains a Naming Table (see ° d ONLN d› §f ∞∂ ( ÃÑ
The TrueType™ ° d ONLN dÎ ∞ < º ø ( ÿ ZFont Format Specification ° d ONLN d ∞ ø º )É, ° d ONLN d ∞ º∂ ) &APDA™ M0825LL/A) which provides nearly ° d ONLN d- º < » î ( ‰ Zunrestricted font ° d ONLN d? º î »∂ )X5naming capabilities, to accommodate the needs of font ° d ONLN du » < ‘ ( Z'manufacturers. A forthcoming Macintosh ° d ONLN dú » ‘∂ )Δ!Technical Note on TrueType Naming ° d ONLN dæ ‘ < ‡ Ê ( ¸ Z$Tables gives additional information. ° d ONLN d„ Ï * ¯ . ( H• ° d ONLN dÂ Ï 7 ¯& )
/QuickDraw and the current Font Manager have no ° d ONLN d Ï& ¯∂ )Ô provision for stylistic variants ° d ONLN d5 ¯ 7# ( U1like “light,” “medium,” “demi,” “book,” “black,” ° d ONLN df ¯#∂ )Ï “heavy,” “extra,” “ultra,” etc., ° d ONLN dá 7 ü (, Uused in the context of ° d ONLN dû ü∂ )h;professional typesetting. Therefore, each of these variants ° d ONLN d⁄ 7 m (8 UAcomes with a separate font family resource. Probably for reasons ° d ONLN dm ∂ (8ãof consistency, ° d ONLN d+ 7( ‹ (D U%the “italic” variants have their own ° d ONLN dP ‹(∂ )•-font family resources as well. Unfortunately, ° d ONLN d~) 75 t (Q U unless each ° d ONLN dä( t4 û )='FOND' ° d ONLN dê) û5T )*% references both the “plain” and the ° d ONLN dµ)T5∂ )∂“italic” font strikes, ° d ONLN dÃ5 7A~ (] UEQuickDraw will no longer know a customized italic font strike exists. ° d ONLN dM 7Yè *JIt is fairly easy, using System 7 and ResEdit, to merge two font families ° d ONLN d]MèY∂ (u≠(named, ° d ONLN deY 7e ¿ (Å Ufor exmaple, “myFont” and ° d ONLN dY ¿e∂ )â/“myFont italic”) into one. This way, QuickDraw ° d ONLN dØe 7q' (ç U4will automatically use the pre-designed italic font ° d ONLN d„e'q∂ ) strike instead of creating one ° d ONLN dq 7} (ô U0algorithmically. Follow these convenient steps: ° d ONLN d4ä *ñ 4 (≤ H1. ° d ONLN d7ä <ñ ô )Make sure there is ° d ONLN dJä ôñO )]$no resource ID conflict between the ° d ONLN dnâOïy )∂'NFNT' ° d ONLN dtäyñô )*s and ° d ONLN dzâôï√ ) 'sfnt' ° d ONLN dÄä√ñ» )*s ° d ONLN dÇñ <¢ ª (æ Zbelonging to both families. ° d ONLN dû¢ *Æ 4 ( H2. ° d ONLN d°¢ <Æ ),Make sure the style bits for italic are set ° d ONLN dբƻ )Δ(in the font association table of “myFont ° d ONLN dˆÆ <∫ [ (÷ Zitalic.” ° d ONLN dˇª *« 4 („ H3. ° d ONLN dª <« é )From ResEdit’s ° d ONLN dª é«l )R)File menu, “Get Info...” on the “myFont” ° d ONLN d:∫lΔñ )fi'FOND' ° d ONLN d@ªñ«» )*
resource. ° d ONLN dL» <‘ ( Z+Write down the resource ID of the “myFont” ° d ONLN dw«”< )÷'FOND' ° d ONLN d}»<‘@ )*. ° d ONLN d’ *· 4 (˝ H4. ° d ONLN dÇ’ <·! )/From ResEdit’s File menu, “Get Info...” on the ° d ONLN d±’!·n )“myFont italic” ° d ONLN d¡‘n‡ò )M'FOND' ° d ONLN d«’ò·» )* . Change ° d ONLN d—· <Ì Ì ( Z'its resource ID to be identical to the ° d ONLN d¯· ÌÌ» )±)one you wrote down in step 3. Change its ° d ONLN d "Ì <˘ ¬ ( Zresource name to “myFont.” ° d ONLN d =˘ * 4 (! H5. ° d ONLN d @˘ <ç )GUse the Finder in System 7 to move the contents of the “myFont italic” ° d ONLN d á˘ç» (!´
suitcase into ° d ONLN d ï < (- Z#the original “myFont” suitcase. It ° d ONLN d ∏ » )¥)will merge all constituents into one font ° d ONLN d ‚ < u (9 Z association ° d ONLN d Ó u » )9Etable, and thus enable transparent substitution of the right font for ° d ONLN d
4 <) ± (E ZQuickDraw’s italic style.
° d ONLN d
NA P å (l 6Version Numbers
° d ONLN d
^\ h ö *The 'FOND' structure (see ° d ONLN d
x\ öh Î )ÇInside Macintosh ° d ONLN d
à\ Îh )Q Volume ° d ONLN d
ê\h⁄ )+'IV, page 45, “FamRec”) contains a field ° d ONLN d
∏h t& (ê 66ffVersion, and inquiring minds naturally want to know ° d ONLN d
Óh&t⁄ (êD$more about it. Before anything else, ° d ONLN d t Ä Ù (ú 6.however, please read the following disclaimer: ◊ 4◊˘
*P4 ) of 12 (Ï∑
Fond of FONDs ˇä ◊# ˇ ˇˇˇˇ # ◊
IR , Times
. +Z-Developer Support Center ( -ÛMay 1992 / X /
° d ONLN d < ) | ( E Z Disclaimer: ° d ONLN d Ñ )é )H3The Font Manager does not check version numbers in ° d ONLN d ? é )⁄ ( E¨
a 'FOND', and ° d ONLN d M ) Ñ 5 ¯ ( Q ¢we recommend that you ° d ONLN d c ) ¯ 5⁄ )t0not rely on the (intentionally vague) statements ° d ONLN d î 5 Ñ A∞ ( ] ¢>below, but rather analyze the data in the 'FOND'independently. ° d ONLN d ” M < Y ó ( u ZCurrently, values ° d ONLN d  M ó Y˛ )[D0...3 may appear in the ffVersion field, with the following intended ° d ONLN d* Y < e Ç ( Å Zinterpretations: ° d ONLN d; q < } m *
Version 0: ° d ONLN dF q { } ¯ )?Usually indicates that the ° d ONLN da q ¯ }˛ )}1'FOND' has been created on the fly by the Font/DA ° d ONLN dì } { â, ( • ô$Mover (or the System 7 Finder). But ° d ONLN d∑ }, Ⲡ)±+the 'FOND' for Palatino on the distribution ° d ONLN d„ â { ï4 ( ± ô&disks of System 7 is a counterexample. ° d ONLN d
ï < ° m ( Ω Z
Version 1: ° d ONLN d ï { ° Ï )?Obviously indicates the ° d ONLN d- ï Ï °¨ )q%first version when 'FOND's came out ( ° d ONLN dR ï¨ °˛ )¿Inside Macintosh ° d ONLN dc ° { ≠ „ ( … ôVolume IV, page 36). ° d ONLN dx ≠ < π m ( ’ Z
Version 2: ° d ONLN dÉ ≠ { π Õ )?Corresponds to ° d ONLN dí ≠ Õ π· )R1the extension of the 'FOND' format documented in ° d ONLN d√ ≠· π˛ ( ’ˇInside ° d ONLN d π { ≈ ¨ ( · ô Macintosh ° d ONLN d” π ¨ ≈ Ø )1 ° d ONLN d‘ π Ø ≈˛ )@Volume V, page 185 (which does not mean that the 'FOND' actually ° d ONLN d ≈ { — ( Ì ô contains a bounding box table). ° d ONLN d5 — < › m ( ˘ Z
Version 3: ° d ONLN d@ — { ›é )?7The 'FOND' is supposed to contain a bounding box table. ° d ONLN dx È < ı T ( ZThis ° d ONLN d} È T ı˛ )Xbrings up an annoying fact. All measurement values (referring to a hypothetical 1-point ° d ONLN d÷ ı < ‚ ( Z$font) in the 'FOND' are in a 16-bit ° d ONLN d˙ ı ‚˛ )¶<fixed-point format, with an integer part in the high-order 4 ° d ONLN d7 <
∞ () Zbits and a fractional part ° d ONLN dR ∞
˛ )tEin the low-order 12 bits. You would expect that negative values (like ° d ONLN dò
< ö (5 Zfor ffDescent, or in ° d ONLN d≠
ö˛ )^Ithe kerning tables) are represented in the usual two’s-complement format, ° d ONLN d˜ <% m (A Z
such that ° d ONLN d m%˛ )1Ostandard binary arithmetic applies. This is mostly true, but not always. Again, ° d ONLN dQ% <1N (M Z8Palatino is a counterexample (and probably not the only ° d ONLN dâ%N1˛ (Ml!one). To our knowledge, version 0 ° d ONLN d´1 <=Õ (Y ZRand version 1 'FOND's have negative values represented in a format where the most ° d ONLN d˝1Õ=˛ (YÎ significant ° d ONLN d = <I (e Z"bit is the sign bit, and the rest ° d ONLN d+= I˛ )é@represents the absolute value. However, there is nothing in the ° d ONLN dlI <Ut (q ZAsystem software that enforces this, so counterexamples may exist. ° d ONLN dÆa <m p *Warning: ° d ONLN d∑a ÑmH )H&Don’t rely on the version number, but ° d ONLN d›aHm⁄ )ƒ include sanity checks for the ° d ONLN d˚m Ñy Ø (ï ¢ negative ° d ONLN dm Øy⁄ )+:values in a 'FOND' instead! The following Pascal function ° d ONLN d?y ÑÖ
(° ¢shows how this can be done: ,
Courier
° d ONLN d[è <ö1 (∂ Z1 FUNCTION Check4p12Value(n: Integer): Integer; ° d ONLN dçô <§≥ *
K { n is a 4.12 fixed-point value; i.e., its "real" value is n/4096. } ° d ONLN dŸ£ <Æ≥ *
K { If n is "unreasonably negative," interpret the most significant bit } ° d ONLN d%≠ <∏≥ *
K { as sign bit, and convert to the usual two's complement format. } ° d ONLN dq¡ <à x * BEGIN ° d ONLN d~À <÷¬ *
N IF n < $8FFF THEN { means: (4.12-interpretation of n) is below - 7 } ° d ONLN dÕ’ <‡, *
E { i.e., mask sign bit, and take negative of absolute value } ° d ONLN d DÈ <Ù Ç *
ELSE ° d ONLN d SÛ <˛ · *
! Check4p12Value := n; ° d ONLN d u˝ < s *
END;
° d ONLN d Å <. *& In the Heart of the Font Manager
° d ONLN d ¢: <F ò *Swapping Fonts ° d ONLN d ±R <^ | *
As stated in ° d ONLN d æR |^ ÿ )@Inside Macintosh, ° d ONLN d –R ÿ^‘ )\0there is only one contact between QuickDraw and ° d ONLN d
R‘^˛ )¸the Font ° d ONLN d
^ <j (Ü Z*Manager: the FMSwapFont function. Each of ° d ONLN d
3^ jú )‡the three QuickDraw text ° d ONLN d
L^újÕ )Ä measuring ° d ONLN d
U^Õj˛ )1
functions ° d ONLN d
`j <v ~ (í Z (CharWidth, ° d ONLN d
lj ~v˛ )BEStringWidth and TextWidth) always ends up in the QuickDraw bottleneck ° d ONLN d
≤v <Çõ (û Z?procedure QDProcs.txMeasProc. Each of the three QuickDraw text ° d ONLN d
ÒvõǬ (ûπdrawing ° d ONLN d
¯v¬Ç˛ )' procedures ° d ONLN d Ç <é` (™ Z7(DrawChar, DrawString and DrawText) always ends up in ° d ONLN d ;Ç`é˛ (™~ the QDProcs.textProc bottleneck ° d ONLN d [é <ö8 (∂ Z2procedure. Any reasonable textProc (like StdText) ° d ONLN d çé8ö˛ )¸*needs to call the currently-installed text ° d ONLN d ∏ö <¶œ (¬ ZLmeasuring bottleneck procedure before actually rendering the text. And what ° d ONLN d öœ¶˛ (¬Ìdoes any ◊ X◊
(Ï Z
Fond of FONDs (Ïˇ5 ) of 12 ˇ ◊# ˇ ˇˇˇˇ # ◊
IR , Times
. +6-Macintosh Technical Notes / 4 /˘
° d ONLN d +ñ *Preasonable text measuring bottleneck procedure(like StdTxMeas) do first, before ° d ONLN d P ñ +⁄ ( G¥anything else? ° d ONLN d _ + 7 É ( S 6It calls FMSwapFont, ° d ONLN d t + É 7⁄ )kHto make sure we are talking about the right font and its properties! (To ° d ONLN d Ω 7 C § ( _ 6 be precise, GetFontInfo and ° d ONLN d Ÿ 7 § C⁄ )å@FontMetrics are the other calls that make sure the right font is ° d ONLN d C Oâ ( k 6Lswapped in and set up, without requiring you to call FMSwapFont explicitly.) ° d ONLN dg [ g Æ * Responding to a font request is ° d ONLN dá [ Æ g⁄ )ñ:a lot of work, and FMSwapFont has been optimized to return ° d ONLN d¬ g s ˘ ( è 62as quickly as possible if the request is the same ° d ONLN dÙ g ˘ s⁄ )·.as the previous one. Building the global width ° d ONLN d# s I ( õ 6 table (see ° d ONLN d. s I j )1Inside ° d ONLN d5 s j õ )! Macintosh ° d ONLN d> s õ ⁄ )1; Volume IV, page 41) is among the more time-consuming tasks ° d ONLN dz ã ˜ ( ß 6,related to FMSwapFont; this is why the Font ° d ONLN d¶ ˜ ã⁄ )fl+Manager maintains a cache of up to 12 width ° d ONLN d“ ã ó 7 ( ≥ 6tables. ° d ONLN d⁄ £ Ø i *Inside Macintosh ° d ONLN dÍ £ i Øæ )QD Volume I, page 220 documents the Font Manager’s choice when a font ° d ONLN d. £æ Ø⁄ ( À‹of the ° d ONLN d5 Ø ª π ( ◊ 6"requested size is not available. ° d ONLN dW Ø π ª⁄ )°6However, some consequences or additional features have ° d ONLN dé ª «> ( „ 6?occasionally been a surprise to developers (and users as well). ° d ONLN dŒ ” fl *)Scaling Factors in FMOutPut and StdTxMeas ° d ONLN d¯ Î ˜ x *Let’s suppose you ° d ONLN d
Á èÛ∂ )/7FMSwapFont are such that txSize*numer.v/denom.v is less ° d ONLN d
<Û `ˇ w ( ~than ° d ONLN d
AÛ wˇ∂ )B0.5 and rounds to 0, and if there is more than one 'sfnt' resource ° d ONLN d
Ñˇ ` 9 (' ~/referenced in the font association table, then ° d ONLN d
≥ˇ9 ∂ )Ÿthe current Font Manager ° d ONLN d
à `É (3 ~>may get confused and return results for the wrong font strike. ° d ONLN d # / Í (K 6"TrueType Always Has the Right Size ° d ONLN d .; G y *The default value of ° d ONLN d C; yG⁄ )aGoutlinePreferred is FALSE. If you have bitmap fonts for Palatino 12 and ° d ONLN d ãG S– (o 6^Palatino 14 in your system as well as a Palatino TrueType font, then requests for Palatino 12 ° d ONLN d ÈG–S⁄ (oÓor ° d ONLN d ÏS _ ({ 65Palatino 14 are fulfilled with the bitmap fonts, but ° d ONLN d !S_⁄ )Ó.requests for any other size are fulfilled with ° d ONLN d P_ k ƒ (á 6%the TrueType font. In particular, if ° d ONLN d u_ ƒk⁄ )¨8you (or, for example, a printer driver) need Palatino 12 ° d ONLN d Æk wC (ì 6>scaled by 2, the Font Manager will actually look for Palatino ° d ONLN d ÏkCw⁄ (ìa 24 and return the outline font, ° d ONLN d
w É ô (ü 6 regardless of the setting of ° d ONLN d
(w ôÉ ù )Å ° d ONLN d
)w ùÉ° )5outlinePreferred. Even if you wanted the bitmap font ° d ONLN d
^w°É⁄ (üø doubled for ° d ONLN d
jÉ è 7 (´ 6exact ° d ONLN d
pÉ 7è⁄ ) M“what-you-see-is-what-you-get” text placement, you’re out of luck—you get the ° d ONLN d
æè õè (∑ 6NTrueType font, which may have very different font metrics or character shapes. ◊ 4◊˘
y )Q0Let’s suppose you have the bitmap font Times 12 ° d ONLN dÛy
˛ )Ï(Normal) and the TrueType ° d ONLN d
çp (5 ´-fonts Times (Normal), Times Italic and Times ° d ONLN d:
p˛ )„Bold in your system. If you ° d ONLN dV ç% ˚ (A ´request Times 14 Italic ° d ONLN dn ˚%˛ )n5or Times 14 Bold, it’s rendered from the Times Italic ° d ONLN d§% ç1Ù (M ´Gor Times Bold TrueType fonts. However, if you ask for Times 12 Italic ° d ONLN dÎ%Ù1˛ (Mor ° d ONLN dÓ1 ç= (Y ´Times 12 Bold, and your ° d ONLN d1=˛ )z4system has the default setting of outlinePreferred = ° d ONLN d;= çI¥ (e ´5FALSE, the Font Manager decides to take the Times 12 ° d ONLN dp=¥I˛ (e“bitmap and let ° d ONLN dI çUœ (q ´HQuickDraw algorithmically slant it (for italics) or smear it (for bold). ° d ONLN d a <m { (â Z
Example 3: ° d ONLN d É çÒ/ )Q%Admittedly, this is less likely (but ° d ONLN d ®Â/Ò˛ )¢(it has happened). Let’s suppose somebody ° d ONLN d —Ò ç˝È ( ´Hdecides to rip the Times TrueType outline out of the System file (don’t ° d ONLN d
ÒÈ˝˛ ( ask ° d ONLN d
˝ ç fi (% ´Dme why—I don’t know). He forgets to take the Times Italic TrueType ° d ONLN d
b˝fi ˛ (%¸outline ° d ONLN d
j ç¡ (1 ´=away as well. The next time he draws text in Times (Normal), ° d ONLN d
ß ¡˛ (1fl
in a size for ° d ONLN d
µ ç! (= ´which there is no bitmap ° d ONLN d
Œ!˛ )Å.font (or if outlinePreferred = TRUE), the Font ° d ONLN d
˝! ç-à (I ´5Manager goes for an 'sfnt', and the text shows up in ° d ONLN d 2!à-û )˚italic ° d ONLN d 8!û-¸ ) (what a surprise!). ° d ONLN d N9 <Eâ (a ZEUnfortunately, given the current implementation of the Font Manager, ° d ONLN d ì9âE˛ (aßthere are no solutions to ° d ONLN d ≠E <Q (m Z%the problems illustrated above—other ° d ONLN d “E Q˛ )¥:than asking users of your application to install the fonts ° d ONLN d
Q <] ‚ (y Z you recommend. The only way ° d ONLN d )Q ‚]˛ )¶8to anticipate these potential surprises from within your ° d ONLN d b] <i (Ö ZTapplication is to look into the 'FOND's font association table. You can’t depend on ° d ONLN d ∂]i˛ (Öthe ° d ONLN d ∫i <u (ë Z+IsOutline function because it returns TRUE ° d ONLN d Âi u˛ )œ2as soon as the Font Manager stops at an 'sfnt', in ° d ONLN d
u <Åi (ù Z@its first pass through the font association table—regardless of ° d ONLN d
XuiÅ˛ (ùá subsequent stylistic variations. ° d ONLN d
◊ç <ôN (µ Z7know if you got the Helvetica Bold TrueType font or if ° d ONLN dçNô˛ (µl!QuickDraw “smeared” the Helvetica ° d ONLN d0ô <• ß (¡ Z(Plain) TrueType font. ◊ X◊
*+
Fond of FONDs (Ïˇ7 ) of 12 ˇ ◊# ˇ ˇˇˇˇ # ◊
IR , Times
. +6-Macintosh Technical Notes / 4 /˘
° d ONLN d 7 F *5 Where Do the Widths Come From?
° d ONLN d R ^7 *;Text measuring (for example, for precise text placement in ° d ONLN d Z R7 ^⁄ ( zU forms with bounding boxes) and ° d ONLN d y ^ j— ( Ü 6^most line layout algorithms for justified text rely heavily on the character widths contained ° d ONLN d ◊ ^— j⁄ ( ÜÔin ° d ONLN d ⁄ j v ( í 65the global width table. Given that under the current ° d ONLN d j v⁄ )Û+font architecture, we may easily have three ° d ONLN d; v ÇL ( û 6?or more different width tables for the same font specification ° d ONLN dz vL Ç⁄ ( ûj (the non-proportional integer ° d ONLN dò Ç éÅ ( ™ 6Fwidths attached to the 'NFNT', the fractional widths contained in the ° d ONLN dfi ÇÅ é⁄ ( ™ü'FOND', and the ° d ONLN dÓ é ö ¶ ( ∂ 6 fractional widths provided by ° d ONLN d é ¶ ö⁄ )é@the 'sfnt'), it is important to understand where the widths come ° d ONLN dM ö ¶ j ( ¬ 6from in any case. ° d ONLN d_ ≤ æ “ *%Since SetFractEnable was introduced ( ° d ONLN dÑ ≤ “ æ$ )∫Inside Macintosh ° d ONLN dî ≤$ æ§ )R Volume IV, page 32 and ° d ONLN d¨ ≤§ æ⁄ )Ä Volume V, ° d ONLN d∂ æ b ( Ê 6page 180), its ° d ONLN d≈ æ b ⁄ )JGsetting TRUE or FALSE was supposed to give predictable effects. If it’s ° d ONLN d
÷¶ ( Ú 6PFALSE, the Font Manager takes the integer widths from the 'NFNT'; if it’s TRUE, ° d ONLN d] ¶ ÷⁄ ( Úƒ it takes the ° d ONLN dj ÷ ‚± ( ˛ 6Tfractional widths from the 'FOND'. Unfortunately, there are some additional details ° d ONLN dæ ÷± ‚⁄ ( ˛œand side ° d ONLN d« ‚ Ó ≠ (
6 effects that are not well known. ° d ONLN dË ˚ *• ° d ONLN dÍ ˚ % ≈ )
!The Font Manager looks at bit 14 ° d ONLN d ˚ ≈C )† of the ffFlags field in the ,
Courier ° d ONLN d' ˙Cm )~'FOND' ° d ONLN d- ˚mà )* (see ° d ONLN d3 ˚à⁄ )Inside Macintosh ° d ONLN dD %à (/ C^Volume IV pages 36 and 37). If it is set (like it is for Courier), the fractional widths from ° d ONLN d¢Ã⁄ (/Íthe ° d ONLN d¶ % O (< C'FOND' ° d ONLN d¨ O c )* are ° d ONLN d± c } )never ° d ONLN d∂ } ù ) used. ° d ONLN dæ , (H 6• ° d ONLN d¿ %, z )
If SetFractEnable ° d ONLN d“ z,⁄ )UKis TRUE and you request a stylistic variation like bold or italic, the Font ° d ONLN d , %8 Ã (T C#Manager looks at bits 12 and 13 of ° d ONLN dA, Ã8⁄ )ß9the ffFlags field to decide how different widths or extra ° d ONLN d{8 %DW (` CDwidths for the stylistic variants have to be used. What it decides ° d ONLN dø8WD⁄ (`uis documented in the “Font ° d ONLN d⁄D %P à (l CManager” chapter of ° d ONLN dÓD àP )cInside Macintosh Preview ° d ONLN dDPN ){, located on the ° d ONLN dDNP± )KDeveloper CD Series ° d ONLN d*D±P– )c discs. ° d ONLN d2P \ (x 6• ° d ONLN d4P %\: )
=Given that it is not possible to set the pen to a fractional ° d ONLN dqP:\⁄ (xX"position, precise text positioning ° d ONLN dî\ %h/ (Ñ C5with fractional widths enabled is always compromised ° d ONLN d…\/h⁄ (ÑM!because of (accumulated) rounding ° d ONLN dÎh %t E (ê Cerrors. ° d ONLN dÛt Ä (ú 6• ° d ONLN dıt %Äê )
HQuickDraw distributes the accumulated rounding errors across characters ° d ONLN d=têÄ⁄ (úÆwithin a string ° d ONLN dMÄ %åe (® CE(instead of adding it at the end of the drawn text). This results in ° d ONLN díÄeå⁄ (®Époor text quality on the ° d ONLN d´å %ò (¥ C-screen, and in problems when calculating the ° d ONLN dÿåò⁄ )Ï'position of the insertion point between ° d ONLN d ò %§ X (¿ C characters. ° d ONLN d § ∞ (à 6• ° d ONLN d§ %∞ ù )
The LaserWriter driver ° d ONLN d%§ ù∞⁄ )x8watches what you pass to SetFractEnable. Passing TRUE to ° d ONLN d^∞ %º5 (ÿ C9SetFractEnable disables some of the LaserWriter driver’s ° d ONLN dó∞5º⁄ (ÿS#line layout features, assuming that ° d ONLN dªº %»H (‰ C;the programmer intends to control text placement manually. ° d ONLN dˆºH»⁄ (‰f Explicitly passing FALSE to ° d ONLN d » %‘ û ( CSetFractEnable achieves ° d ONLN d +» û‘⁄ )y<different results than using the default value of FALSE—Font ° d ONLN d h‘ %‡ ä (¸ CSubstitution behaves ° d ONLN d }‘ ä‡⁄ )eCdifferently, for example. These effects are sometimes Not What You ° d ONLN d ¡‡ %Ï M ( CWanted. ° d ONLN d …Ï ¯ ( 6• ° d ONLN d ÀÏ %¯; )
7On non-32-Bit-QuickDraw systems, SetFractEnable is not ° d ONLN d
Ï;¯⁄ (Y"recorded in pictures. This affects ° d ONLN d
%¯ % p ( Cthe line layout ° d ONLN d
5¯ p⁄ )KFof text reproduced through DrawPicture if the picture was created with ° d ONLN d
| % ü (, Cfractional widths enabled. ° d ONLN d
ó (! (D 66In systems with TrueType, quite naturally the widths ° d ONLN d
FALSE and ° d ONLN d ≥@ SL⁄ );Tno 'hdmx' table is present or it contains no entries for the desired point size, the ° d ONLN d L Xn (t 6Kfractional character widths from the 'sfnt' are rounded to integral values. ° d ONLN d Td p ∂ *More Line Layout Problems ° d ONLN d n| à õ *The routines SpaceExtra ( ° d ONLN d á| õà Ô )ÉInside Macintosh ° d ONLN d ó| Ôà ı )T ° d ONLN d ò| ıàΩ )#Volume I, page 172) and CharExtra ( ° d ONLN d ª|Ωà⁄ )»Inside ° d ONLN d ¬à î M (∞ 6
Macintosh ° d ONLN d Ãà Mî v )5Volume ° d ONLN d ”à vî⁄ ))GV, page 77; available only in color GrafPorts) are intended to help you ° d ONLN d
î † (º 62draw fully justified text. This works fine on the ° d ONLN d
Mî†⁄ )Ï-screen, but not all printer drivers are smart ° d ONLN d
{† ¨^ (» 6Denough to use these settings appropriately under all circumstances. ° d ONLN d
ø†^¨⁄ (»|In particular, if you pass ◊ 4◊˘
(Ï 68 ) of 12 (Ï∑
Fond of FONDs ˇÊ ◊# ˇ ˇˇˇˇ # ◊
IR , Times
. +Z-Developer Support Center ( -ÛMay 1992 / X /
° d ONLN d < ) ∏ ( E ZTRUE to SetFractEnable, ° d ONLN d ∏ )˛ )|Eor if you turn the LaserWriter driver’s line layout algorithm off (by ° d ONLN d ^ ) < 5– ( Q ZOmeans of the picture comment LineLayoutOff; see Macintosh Technical Note #91), ° d ONLN d ≠ )– 5˛ ( QÓ
or if font ° d ONLN d ∏ 5 < A: ( ] Z:substitution is enabled and actually occurs, it is better ° d ONLN d Ú 5: A˛ )˛'not to rely on SpaceExtra and CharExtra ° d ONLN d A < M• ( i ZPwhen printing fully justified text. Instead, keep the LaserWriter driver’s line ° d ONLN dj A• M˛ ( i√layout adjustments ° d ONLN d} M < Yu ( u Z@off, and calculate the placement of your text (word by word, or ° d ONLN dΩ Mu Y˛ ( uì even character by character) ° d ONLN d⁄ Y < e g ( Å Z yourself.
O r := bdsA^; { The bounding box rectangle is in TrueType coordinates. } ° d ONLN d K^ <ih *
< temp := r.bottom; { need to flip it "upside down" } ° d ONLN d àh <s Õ *
r.bottom := - r.top; ° d ONLN d ¶r <} π *
r.top := - temp; ° d ONLN d ¿| <á ı *
% OffsetRect(r,leftEdge,pt.v); ° d ONLN d ÊÜ <ëh *
< FrameRect(r); { This is the glyph's bounding box. } ° d ONLN d
#ê <õ *
$ advance := advance + advA^; ° d ONLN d
Hö <•Æ *
J { "Advance" is Fixed, to avoid accumulation of rounding errors. } ◊ X◊
*+
Fond of FONDs (Ïˇ9 ) of 12 ˇT ◊# ˇ ˇˇˇˇ # ◊
IR , Times
. +6-Macintosh Technical Notes / 4 /˘ ,
Courier
° d ONLN d * */ { Now, bump pointers for next glyph. } ° d ONLN d 0 ) 4 *
4 bdsA := RectPtr(ord4(bdsA) + SizeOf(Rect)); ° d ONLN d e 3 >& *
6 advA := FixedPtr(ord4(advA) + SizeOf(Fixed)); ° d ONLN d ú = H& *
6 lsbA := FixedPtr(ord4(lsbA) + SizeOf(Fixed)); ° d ONLN d ” G R J *
END; ° d ONLN d fi Q \ ü *
DisposPtr(Ptr(advA)); ° d ONLN d ˙ [ f ü *
DisposPtr(Ptr(lsbA)); ° d ONLN d e p ü *
DisposPtr(Ptr(bdsA)); ° d ONLN d2 o z ü *
END; { DrawBoxedString }
° d ONLN dN Ö ë a *OutlineMetrics ° d ONLN d] Ö a ë⁄ )IJexists because many developers need pixel-precise information on placement ° d ONLN d® ë ù ` ( π 6
Macintosh ° d ONLN dM ˝ M « )5Volume I, page 227 and ° d ONLN dd ˝ « ⁄ )z6Volume IV, page 41) suggests it’s possible to devise a ° d ONLN dõ ´ (1 6Qroutine for determining a fairly precise text bounding box for bitmap fonts. The ° d ONLN dÏ ´⁄ (1… procedure ° d ONLN dˆ ! ? (= 6below, ° d ONLN d˛ ?!⁄ )'SBitmapTextBoundingBox, is a first attempt. It assumes that TrueType is unavailable, ° d ONLN dR! -6 (I 6:or that the IsOutline call returned FALSE for the current ° d ONLN då!6-⁄ (IT!port settings. While the returned ° d ONLN dÆ- 9ó (U 6Nbounding box is not always “tight,” be careful before modifying the algorithm ° d ONLN d¸-ó9⁄ (Uµ
and shrinking ° d ONLN d
9 EΩ (a 6Wthe resulting bounding box—bitmap fonts just don’t contain enough precise information ° d ONLN da9ΩE⁄ (a€for an ° d ONLN dhE Qä (m 6Gexact bounding box, and different bitmap fonts and different sizes may ° d ONLN dØEäQ⁄ (m®require different ° d ONLN d¡Q ] T (y 6 adjustments.
° d ONLN dŒi tÄ *HPROCEDURE TextBoundingBox(s: Str255; numer,denom: Point; VAR box: Rect); ° d ONLN d} à @ * CONST ° d ONLN d á íS *
? FMgrOutRec = $998; { FMOutRec starts here in low memory } ° d ONLN d`ë ú Å *
tabFont = 1024; ° d ONLN dvõ ¶Ä *
H { global width table offset for font record handle, see IM IV-41 } ° d ONLN døØ ∫ ; * TYPE ° d ONLN d«π ƒ § *
FontRecPtr = ^FontRec; ° d ONLN d‰Õ ÿ 6 * VAR ° d ONLN dÎ◊ ‚ ü *
hScale,vScale: Fixed; ° d ONLN d· Ï € *
' err,intWidth,kernAdjust: Integer; ° d ONLN d/Î ˆ h *
xy: Point; ° d ONLN d@ı l *
D info: FontInfo; { only for StdTxMeas; we'll use FontMetrics } ° d ONLN dÖˇ
& *
6 fm: FMetricRec; { see Inside Macintosh, IV-32 } ° d ONLN dº Ü *
fmOut: FMOutput; ° d ONLN d” h *
h: Handle; ° d ONLN d‰' 2 @ * BEGIN ° d ONLN dÌ1 <N *
> intWidth := StdTxMeas(ord(s[0]),@s[1],numer,denom,info); ° d ONLN d ,; F Ô *
+ { calls FMSwapFont and everything - } ° d ONLN d XE Pä *
J { StdTxMeas returns possibly modified scaling factors numer, denom } ° d ONLN d £O Z Í *
* hScale := FixRatio(numer.h,denom.h); ° d ONLN d œY d Í *
* vScale := FixRatio(numer.v,denom.v); ° d ONLN d ˙c n5 *
9 { These are the scaling factors QuickDraw uses } ° d ONLN d
4m x5 *
9 { in "stretching" the available character bitmaps } ° d ONLN d
nw Ç — *
% fmOut := FMOutPtr(FMgrOutRec)^; ° d ONLN d
îÅ å5 *
9 { has been filled by the most recent FMSwapFont, } ° d ONLN d
Œã ñ  *
) { implicitly called by StdTxMeas } ° d ONLN d
¯ï †: *
: SetRect(box,0, - info.ascent,intWidth,info.descent); ° d ONLN d 3ü ™ ˛ *
. { bounding box for unscaled plain text } ◊ 4◊˘
*&10 )
of 12 (Ï∑
Fond of FONDs ˇP ◊# ˇ ˇˇˇˇ # ◊
IR , Times
. +Z-Developer Support Center ( -ÛMay 1992 / X / ,
Courier
° d ONLN d < (ü ( D ZG IF (italic IN thePort^.txFace) AND (fmOut.italic <> 0) THEN BEGIN ° d ONLN d H ' < 2 ˇ *
' { the following is heuristics … } ° d ONLN d p 1 < <ê *
D box.right := box.right + (info.ascent + info.descent - 1) * ° d ONLN d µ ; < F *
* fmOut.italic DIV 16; ° d ONLN d ‡ E < P π *
FontMetrics(fm); ° d ONLN d ˙ O < Zê *
D HLock(fm.WTabHandle); { We'll point to global WidthTable. } ° d ONLN d? Y < dw *
? h := Handle(LongPtr(ord4(fm.WTabHandle^) + tabFont)^); ° d ONLN d c < n^ *
: { Be sure it's a handle to a 'NFNT' or 'FONT' ! } ° d ONLN d∫ m < x' *
/ kernAdjust := FontRecPtr(h^)^.kernMax; ° d ONLN dÍ w < Ç *
) OffsetRect(box, - kernAdjust,0); ° d ONLN d Å < å ‹ *
HUnlock(fm.WTabHandle); ° d ONLN d5 ã < ñ n *
END; ° d ONLN d@ ï < †m *
= IF (bold IN thePort^.txFace) AND (fmOut.bold <> 0) THEN ° d ONLN d~ ü < ™c *
I { Note that some of the adjustments are based on trial and error… } ° d ONLN dò <h *
< box.top := FixRound(FixMul(Long2Fix(box.top),vScale)); ° d ONLN d’
<Ü *
B box.left := FixRound(FixMul(Long2Fix(box.left),hScale)) - 1; ° d ONLN d <"ö *
F box.bottom := FixRound(FixMul(Long2Fix(box.bottom),vScale)) + 1; ° d ONLN d_! <,ê *
D box.right := FixRound(FixMul(Long2Fix(box.right),hScale)) + 1; ° d ONLN d§+ <6 ë *
GetPen(xy); ° d ONLN d∂5 <@ ‹ *
OffsetRect(box,xy.h,xy.v); ° d ONLN d◊? <J _ *
END;
° d ONLN dfla <p Ö *&
Conclusion
° d ONLN dÍ| <à ‡ *#At the time when the original Font ° d ONLN d
| ‡à˛ )§7Manager architecture was designed, based on QuickDraw’s ° d ONLN dEà <î u (∞ Z hard-coded ° d ONLN dPà uî˛ )9O72 dpi resolution, nobody could anticipate that some years later, the Macintosh ° d ONLN d†î <† ˝ (º Z%would be used to tackle professional ° d ONLN d≈î ˝†˛ )¡2typesetting projects. Several advanced page layout ° d ONLN d¯† <¨h (» Z@applications managed to work around the “built-in” limitations, ° d ONLN d8†h¨˛ (»Ü at high development costs, and ° d ONLN dW¨ <∏Ø (‘ ZBsome compatibility and performance problems. In many other cases, ° d ONLN dô¨Ø∏˛ (‘Õhowever, those ° d ONLN d®∏ <ƒ ì (‡ Zlimitations caused ° d ONLN dª∏ ìƒ˛ )WFquestions to DTS and unsatisfying compromises. This Note can’t do much ° d ONLN dƒ <–Ω (Ï ZOmore than explain the state of affairs; the real solution to the problems must ° d ONLN dQƒΩ–˛ (Ï€ come from a ° d ONLN d]– <‹ ¯ (¯ Z&redesigned foundation. TrueType leads ° d ONLN dÉ– ¯‹˛ )º6the way and already fulfills many of the requirements; ° d ONLN d∫‹ <Ë ( Z-everything else is getting closer and closer. ° d ONLN dË < ¶ *$Further Reference: + X+ ° d ONLN d˚
N R +
• ° d ONLN d˝
` ± )Inside Macintosh ° d ONLN d
±w )Q', Volume I, Chapter 7, The Font Manager ° d ONLN d 5 N% R (A l• ° d ONLN d 7 `% ± )Inside Macintosh ° d ONLN d G ±% )Q(, Volume IV, Chapter 5, The Font Manager ° d ONLN d p% N1 R (M l• ° d ONLN d r% `1 ± )Inside Macintosh ° d ONLN d Ç% ±1{ )Q', Volume V, Chapter 9, The Font Manager ° d ONLN d ™1 N= R (Y l• ° d ONLN d ¨1 `= ± )Inside Macintosh ° d ONLN d º1 ±=Ö )Q), Volume VI, Chapter 12, The Font Manager ° d ONLN d Ê= NI R (e l• ° d ONLN d Ë= `I ) New & Improved Inside Macintosh ° d ONLN d
=Iö )® , Imaging: The Font Manager. ° d ONLN d
$=öIÕ )í
Developer ° d ONLN d
.=ÕI˛ )3 CD Series ° d ONLN d
8I `UΔ (q ~Jdisc, path Developer Essentials: Technical Docs: Inside Macintosh Previewf ° d ONLN d
ÉU Na R (} l• ° d ONLN d
ÖU `aú )<Macintosh Technical Note #91, Picture Comments—The Real Deal ° d ONLN d
¬a Nm R (â l• ° d ONLN d
ƒa `m ∫ )M.IM. FontNames ° d ONLN d
‘m Ny R (ï l• ° d ONLN d
÷m `y – )M.TE.FontsAndScripts ° d ONLN d
Îy NÖ R (° l• ° d ONLN d
Ìy `Ö æ )M.IM.FontFamilies ° d ONLN d
ˇÖ Në R (≠ l• ° d ONLN d Ö `ë Å )Apple ° d ONLN d Ö Åë ¯ )!LaserWriter Reference, ° d ONLN d Ö ¯ë˛ )w/Chapter 2, Working With Fonts ( Addison-Wesley, ° d ONLN d Në `ù | (π ~1988) ◊ X◊
(Ï Z
Fond of FONDs (Ï˙11 )
of 12 ˇˆ ◊# ˇ ˇˇˇˇ # ◊
IR , Times
. +6-Macintosh Technical Notes / 4 /˘
° d ONLN d * + . +• ° d ONLN d < +L )1Adobe Technical Note #0091 (PostScript Developer ° d ONLN d 3 L +⁄ ( GjSupport Group), Macintosh ° d ONLN d M + < 7 ê ( S ZFOND Resources ° d ONLN d \ C Oï ( k 6MPostScript and Adobe are registered trademarks of Adobe Systems Incorporated. ° d ONLN d ™ O [∂ * XHelvetica and Palatino are registered trademarks of Linotype AG and/or its subsidiaries. ° d ONLN d g s J * Velocio is ° d ONLN d g J s \ )2not ° d ONLN d g \ s Ÿ ) a trademark of the author. ◊ 4◊˘
(Ï 612 )
of 12 (Ï∑
Fond of FONDs ˇj ◊# ˇ ˇˇˇˇ # ◊ † Ç
/ Z Å#
0Ià:µú9 " { ˇˇˇˇˇˇˇˇ # † ƒ ° d
ONLN f ˛ † å ° d 1drw2 … -·_ Ä ˇˇˇˇˇˇ è ° ñ x ° d drw2 : ° d drw2 : $ ° d 4drw2 : ° ö ˇ˙ ó@ † ò , Times
. R… R… +]BNew Technical Notes † ô ° d drw2 : °„ † ó ° d 1drw2 eÙ Ä ˇˇˇˇˇˇ P ° ñ x ° d drw2 : ° d drw2 : $ ° d 4drw2 : ° ö ˇ˚Ä E¿ † ò
( {ïDeveloper Support † ô ° d drw2 : °„ † ó ° d `drw2 - Ô ˇˇˇˇˇˇ K Ô - Z f f Z ° d 1drw2 ¿˙È ˇˇˇˇˇˇ K ° ñ x ° d drw2 : ° d drw2 : $ ° d 4drw2 : 0 ° ö ˇÙ Ä † ò
0 ( UÔ † ô ° d drw2 : °„ † ó ° d 1drw2 ÔÊ˙ ˇˇˇˇˇˇ ° ñ x ° d drw2 : ° d drw2 : $ ° d 4drw2 : ° ö ˇ˝Ä † ò
+& ® † ô ° d drw2 : °„ † ó ° d 1drw2  -¯ y ˇˇˇˇˇˇ ° ñ x ° d drw2 : ° d drw2 : $ ° d 4drw2 : ° ö ˇ˚Ä % † ò
( Z \ Macintosh † ô ° d drw2 : °„ † ó † ç ° d drw2 D † É
IR . ° d ONLN d n < Å Á ( õ ZFont Manager Q&As
° d ONLN d Ä < è Z *Text ° d ONLN d Äk è˛ ( ´âM.TX.FontMgr.Q&As
° d ONLN d * õ < ß t ( √ Z Revised by: ° d ONLN d 6 õ Ñ ß ˇ )HDeveloper Support Center ° d ONLN d O õæ ߲ ( √‹ October 1992 ° d ONLN d \ ß < ≥ q ( œ Z Written by: ° d ONLN d h ß Ñ ≥ ˇ )HDeveloper Support Center ° d ONLN d Å ßæ ≥˛ ( œ‹ October 1990 ° d ONLN d é ø < À ⁄ ( Á Z This Technical Note contains a ° d ONLN d ≠ ø ⁄ À˛ )û9collection of Q&As relating to a specific topic—questions ° d ONLN d Á À < ◊† ( Û ZGyou’ve sent the Developer Support Center (DSC) along with answers from ° d ONLN d. À† ◊˛ ( Ûæthe DSC engineers. ° d ONLN dA ◊ < „ u ( ˇ Z
While DSC ° d ONLN dK ◊ u „˛ )9Lengineers have checked the Q&A content for accuracy, the Q&A Technical Notes ° d ONLN dò „ < Ô q ( Z don’t have ° d ONLN d£ „ q Ô˛ )5Qthe editing and organization of other Technical Notes. The Q&A function is to get ° d ONLN dı Ô < ˚ Ÿ ( Z new technical information and ° d ONLN d Ô Ÿ ˚˛ )ù6updates to you quickly, saving the polish for when the ° d ONLN dJ ˚ < (# Z,information migrates into reference manuals. ° d ONLN dw < k *:Q&As are now included with Technical Notes to make access ° d ONLN d±k ˛ (;â to technical updates easier for ° d ONLN d— <+. (G Z/you. If you have comments or suggestions about ° d ONLN d .+˛ )Ú*Q&A content or distribution, please let us ° d ONLN d++ <7 \ (S Zknow ° d ONLN d0+ \7˛ ) Iby sending an AppleLink to DEVFEEDBACK. Apple Partners may send technical ° d ONLN dz7 <Ci (_ Z9questions about Q&A content to DEVSUPPORT for resolution. ° d ONLN d¥O <[« *NNew Q&As and Q&As revised this month are marked with a bar in the side margin. "n Ü XÜ
° d ONLN dÄ <è† *43Chicago Control-Q prints propeller or clover symbol
° d ONLN d7è <õ b * Written: ° d ONLN d@è àõ ¶ )L7/4/90 ° d ONLN dGõ <ß Å (√ ZLast reviewed: ° d ONLN dVõ àß ¶ )L8/1/92 ° d ONLN d]≥ <ø p (€ Z How do I ° d ONLN df≥ pø˛ )4Pget the character that represents the clover used for command-key equivalents in ° d ONLN d∑ø <À ∂ (Á Zdocuments and in menus? ° d ONLN dœÀ <◊ N * ___ ° d ONLN d”„ <Ôç *DThis key is documented in the Apple Style Guide, which is available ° d ONLN d„çÔ˛ ( ´on the latest Developer ° d ONLN d/Ô <˚ º ( ZCD Series disc as well as ° d ONLN dIÔ º˚˛ )Ä=from APDA. One little feature of Key Caps which is not widely ° d ONLN dá˚ < ß (# Zknown is the Control ° d ONLN dú˚ ߲ )kAkey (not the Command or Option keys). Pressing the Control key in ° d ONLN dfi <> (/ Z4Chicago shows that Control-Q in Chicago maps to the ° d ONLN d>˛ (/\&propeller symbol for which you search. ° d ONLN d9 < p (; Z
Control-Q ° d ONLN dC p · )4Kgenerates the character code 17; the standard Macintosh character set (see ° d ONLN dé· ˛ (;ˇInside ° d ONLN dï <+ m (G Z Macintosh ° d ONLN dû m+b )14 Volume VI, page 12-5) specifies this symbol for it. ◊ X◊
userdict /_cv known not{userdict /_cv 30 dict put}if
_cv begin
/bdf{bind def}bind def
currentscreen/cs exch def/ca exch def/cf exch def
/setcmykcolor where{/setcmykcolor get /cvcmyk exch def}{/cvcmyk{1 sub 4 1 roll 3{3 index add neg dup 0 lt{pop 0}if 3 1 roll}repeat setrgbcolor pop}bdf }ifelse
/ss{//cf //ca //cs setscreen}bdf
/stg{ss setgray}bdf
/strgb{ss setrgbcolor}bdf
/stcmyk{ss cvcmyk}bdf
/min1{dup 0 eq{pop 1}if}bdf
end
currentdict /bn known {bn}if
† ø¶ ◊# ˇ ˇˇˇˇ # ◊
IR , Times
. +6-Macintosh Technical Notes / 4 /˘
° d ONLN d ) 8" *'&Determining Macintosh system font size
° d ONLN d ' 8 D > * Written: ° d ONLN d 0 8 d D à )L2/11/91 ° d ONLN d 8 D P ] ( l 6Last reviewed: ° d ONLN d G D d P Ç )L8/1/92 ° d ONLN d N \ h5 ( Ñ 6:How does a program determine the default system font size? ° d ONLN d â h t * * ___ ° d ONLN d ç Ä å Ï *'If you want to know the default system ° d ONLN d ¥ Ä Ï å⁄ )‘.font size, use the GetDefFontSize call (Inside ° d ONLN d „ å ò — ( ¥ 6$Macintosh Volume V, page 314). This ° d ONLN d å — ò⁄ )π:call will return the true default system font size. On all ° d ONLN dB ò §C ( ¿ 6:Roman systems the sysFontSize low-memory global is always ° d ONLN d| òC §⁄ ( ¿a zero by default; this means that ° d ONLN dù § ∞_ ( à 6Hit’s actually 12. Don’t ask me why they did this, but it’s true, so you ° d ONLN d §_ ∞⁄ ( Ã}should use the call if you ° d ONLN d ∞ º“ ( ÿ 6_want a painless method of obtaining this information. Try to avoid reading the global directly.
° d ONLN d` ‘ „M *',FScaleDisable and Macintosh screen rendering
° d ONLN dç „ Ô > * Written: ° d ONLN dñ „ d Ô Ç )L6/4/91 ° d ONLN dù Ô ˚ ] ( 6Last reviewed: ° d ONLN d¨ Ô d ˚ Ç )L8/1/92 ° d ONLN d≥ ‹ (/ 6+What is the current interface guideline on ° d ONLN dfi ‹⁄ )ƒ4font scaling? Should we set FScaleDisable to true or ° d ONLN d c (; 6false for screen ° d ONLN d$ c ⁄ )KQrendering? I believe the old guideline was to set it to true (thus disabling font ° d ONLN dv +ï (G 6Sscaling) so that if you have a 23 pt screen font you will see 12 pt glyphs with 23 ° d ONLN d… ï+⁄ (G≥
pt widths. We ° d ONLN d◊+ 7& (S 62want performance on Apple’s low-end machines, and ° d ONLN d +&7⁄ (SD!we don’t want to make this a user ° d ONLN d+7 C M (_ 6 preference. ° d ONLN d7C O * * ___ ° d ONLN d;[ g â *Most applications now ° d ONLN dQ[ âg⁄ )qEset FScaleDisable to false all the time. If you are worried about the ° d ONLN dóg s ï (è 6speed degradation in your ° d ONLN d±g ïs⁄ )}?application when running on slower Macintosh systems, you could ° d ONLN dÒs Ω (õ 6"have your software identify which ° d ONLN ds Ω⁄ )•:Mac it is running on using Gestalt, SysEnvirons, etc., and ° d ONLN dN ã≥ (ß 6Tthen set FScaleDisable to true only on the slow machines. From the purely interface ° d ONLN d¢≥ã⁄ (ß—point of ° d ONLN d´ã ó| (≥ 6Kview, “what-you-see-is-what-you-get” is best, if processor speed allows it. ° d ONLN d˜£ Ø º *!With TrueType there is no issue, ° d ONLN d£ ºØ⁄ )§9since FScaleDisable doesn’t have any effect on an outline ° d ONLN dRØ ª / (◊ 6font.
° d ONLN dZ” ‚1 *'(Macintosh double-byte character encoding
. +Z-Developer Support Center ( -Ê October 1992 / X /
° d ONLN d < ,_ ( H Z*'FOND' resource features subject to change
° d ONLN d + , < 8 b * Written: ° d ONLN d 4 , à 8 ¨ )L6/17/91 ° d ONLN d < 8 < D Å ( ` ZLast reviewed: ° d ONLN d K 8 à D ¶ )L8/1/92 ° d ONLN d R P < \¢ ( x ZJWhich 'FOND' features are subject to change, and what parts can I rely on? ° d ONLN d ù \ < h N * ___ ° d ONLN d ° t < ÄA *4'FOND' features not documented in Inside Macintosh, ° d ONLN d ’ tA IJ ( ú_%Macintosh Technical Notes, or develop ° d ONLN d ˚ Ä < å ( ® Z0are subject to change. That’s the official word.
° d ONLN d, § < ≥* *'$Five font style-mapping table styles
° d ONLN dQ ≥ < ø b * Written: ° d ONLN dZ ≥ à ø ¨ )L6/17/91 ° d ONLN db ø < À Å ( Á ZLast reviewed: ° d ONLN dq ø à À ¶ )L8/1/92 ° d ONLN dx ◊ < „i ( ˇ Z?Why is “47” the bounds of the indexes’ array in the StyleTable? ° d ONLN d∏ „ < Ô N * ___ ° d ONLN dº ˚ <ù *HThe style-mapping tables, which are used for mapping of a font style to ° d ONLN d ˚ù˛ (#ªa particular font for ° d ONLN d <{ (/ ZGprinting, have only five possible styles, unlike the six screen styles ° d ONLN da{˛ (/ô (underline is omitted, since ° d ONLN d~ < é (; ZIa laser printer just explicitly draws a line under the string—it doesn’t ° d ONLN d«é ˛ (;¨need a special font for ° d ONLN dfl <+Ë (G ZPthat). You can have any combination of these five styles, EXCEPT that you can’t ° d ONLN d/ Ë+˛ (Ghave ° d ONLN d4+ <7Ù (S ZW“Condense” and “Extend” at the same time (Condensed Extended wouldn’t make a whole lot ° d ONLN dã+Ù7˛ (Sof ° d ONLN dé7 <C (_ Z)sense). Thus you get (combinatorics come ° d ONLN d∑7C˛ )À2back to haunt us) 48 possible unique styles to map ° d ONLN dÍC <O I (k Zto. ° d ONLN dÓ[ <g ] *X-Ref: ° d ONLN dıg <s * 'Snippet “StyleMap” on the Developer CD. ° d ONLN d s <Œ * NLaserWriter Reference, Chapter 2, “Working with Fonts,” (Addison-Wesley; APDA ° d ONLN dksŒ˛ (õÏ #M7073, ° d ONLN dt <ã f (ß Z$19.95).
° d ONLN d}£ <≤ ˘ *'System 7 and modified fonts
° d ONLN dô≤ <æ b * Written: ° d ONLN d¢≤ àæ ¨ )L6/21/91 ° d ONLN d™æ < Å (Ê ZLast reviewed: ° d ONLN dπæ à ¶ )L8/1/92 ° d ONLN d¿÷ <‚ Ó (˛ Z!We ship modified versions of the ° d ONLN d·÷ Ó‚˛ )≤/Chicago and Geneva fonts and their FONDs in our ° d ONLN d‚ <Ó (
Z)application’s resource fork. With System ° d ONLN d:‚Ó˛ ) /6, when we ask for font 0 or font 3, we get our ° d ONLN djÓ <˙· ( ZWmodified fonts in windows, buttons, menus and dialogs, but not with System 7. Is there ° d ONLN d¡Ó·˙˛ (ˇa new ° d ONLN d«˙ <‹ (" ZYway to tell System 7 to use my version of Chicago 12 to display all system related stuff? ° d ONLN d! < N * ___ ° d ONLN d% <*q *?What’s happened is that the system software is being much more ° d ONLN dd q*˛ (Fè strict about whose “Chicago” ° d ONLN dÅ* <6 n (R Z it uses for ° d ONLN dç* n6˛ )2Lmenus and dialogs. The Menu and Control Managers now only look at the system ° d ONLN d⁄6 <B ≈ (^ Z file for the Chicago they use. ° d ONLN d˘N <Z „ *"There are a couple of ways to get ° d ONLN dN „Z˛ )ß9around this: First, you can try patching DrawString right ° d ONLN dUZ <f º (Ç Zbefore calling MenuSelect ° d ONLN doZ ºf˛ )Ä=in your program. The patch would select your Chicago and then ° d ONLN d≠f <r ˛ (é Z'jump to the standard DrawString. After ° d ONLN d‘f ˛r˛ )¬1MenuSelect, remove the patch. The disadvantage of ° d ONLN dr <~ ± (ö Zthis method is that, if a ° d ONLN d r ±~˛ )uAfuture system software release doesn’t use DrawString for drawing ° d ONLN db~ <ä# (¶ Z0menus, the patch would cease to have any effect. ◊ X◊
° d ONLN d^ Ï ¯ > * Written: ° d ONLN dg Ï d ¯ é )L12/10/91 ° d ONLN dp ¯ ] ( 6Last reviewed: ° d ONLN d ¯ d Ç )L8/1/92 ° d ONLN dÜ ‡ (8 6&What typographical measurement issues ° d ONLN d¨ ‡ ⁄ )».must be considered for Spanish systems? Do the ° d ONLN d€ (4 (D 6=Spanish specify type in ciceros and didots instead of points? ° d ONLN d( 4 * * ___ ° d ONLN d @ L¨ *SIf typesetting is done in Spain with computers, U.S. standards generally are used. ° d ONLN dp@¨L⁄ (h
It is only ° d ONLN d{L X≥ (t 6Vwhen typesetting is done the old-fashioned way that you’ll see different measurements. ° d ONLN d“d p" *8Paper sizes are different. In Spain DIN-44 (210 x 297), ° d ONLN d
d"p⁄ (å@#DIN-A3 (420 x 297) and “folio” (215 ° d ONLN d.p | ! (ò 6x ° d ONLN d0p !|⁄ ) X315) are used. As always, you’ll be working with 72 dpi for the screen (and any time you ° d ONLN dâ| à Ÿ (§ 6'use QuickDraw) but something different ° d ONLN d∞| Ÿà⁄ )¡3on paper, so you’ll need to use PrGeneral and image ° d ONLN d‰à îå (∞ 6Qthe stuff yourself to a resolution that allows you control over your imaging for ° d ONLN d5àåî⁄ (∞™printing. This is ° d ONLN dGî † ˚ (º 6.detailed in the article, “Meet PrGeneral, the ° d ONLN duî ˚†⁄ )„(Trap That Makes the Most of the Printing ° d ONLN dû† ¨ π (» 6!Manager,” in issue #3 of develop. ° d ONLN d¿∏ ƒ › *(Here are the measurements used in Spain: ° d ONLN dÈ– ‹ « *#• Decimal point (Didot) (0.3759 mm) ° d ONLN d
‹ Ë O * • Millimeter ° d ONLN dË Ù ú * • Cicero (12 decimal points) ° d ONLN d7Ù R * • Centimeter ° d ONLN dD > * • Inches ◊ 4◊˘
*ƒ4 ) of 8 (Ï£Font Manager Q&As ˇT ◊# ˇ ˇˇˇˇ # ◊
IR , Times
. +Z-Developer Support Center ( -Ê October 1992 / X /
° d ONLN d ) < 83 ( T Z"SetOutlinePreferred = TRUE or not?
° d ONLN d # 8 < D b * Written: ° d ONLN d , 8 à D ¨ )L12/2/91 ° d ONLN d 4 D < P Å ( l ZLast reviewed: ° d ONLN d C D à P ¶ )L8/1/92 ° d ONLN d J \ < hÌ ( Ñ ZUMy application calls SetOutlinePreferred so outline fonts are used if both bitmapped ° d ONLN d ü \Ì h˛ ( Ñ and ° d ONLN d £ h < t n ( ê Z TrueType ° d ONLN d ¨ h n t˛ )2Pfonts are in the system. It was reported to me, however, that some international ° d ONLN d ˝ t < Ä € ( ú Z"TrueType fonts in particular look ° d ONLN d t € IJ )ü=really bad at small point sizes on the screen. Should I avoid ° d ONLN d] Ä < å û ( ® Zcalling this function? ° d ONLN dt å < ò N * ___ ° d ONLN dx § < ∞„ *XSetOutlinePreferred is best used as a user-selectable option. Along the same lines, you ° d ONLN d– §„ ∞˛ ( Ãmight ° d ONLN d÷ ∞ < º b ( ÿ Zwant to ° d ONLN dfi ∞ b º˛ )&Rinclude the SetPreserveGlyph call (Inside Macintosh Volume VI, page 12-21), again, ° d ONLN d1 º < » ª ( ‰ Z as a user-selectable option. ° d ONLN dN ‘ < ‡ Ó *$Currently, as you know, the default ° d ONLN dr ‘ Ó ‡˛ )≤8for outlinePreferred is FALSE; this is for compatibility ° d ONLN d´ ‡ < Ï ˜ ( Z&reasons (existing documents don’t get ° d ONLN d— ‡ ˜ Ï˛ )ª6reflowed if the bitmap fonts are still around) and for ° d ONLN d Ï < ¯Ê ( ZYesthetic and performance reasons (users are free to maintain bitmap fonts in the smaller ° d ONLN da ÏÊ ¯˛ (point ° d ONLN dg ¯ <Ä ( ZHsizes if the TrueType version is not satisfying for small sizes, or too ° d ONLN dØ ¯Ä˛ ( ûslow). On the other hand, ° d ONLN d… < | (, Z
as soon as a ° d ONLN d÷ |˛ )@Obitmap font is *un*available for a requested point size, and an outline font is ° d ONLN d& < ” (8 Z"present, the outline font is used ° d ONLN dH ” ˛ )ó<even with outlinePreferred = FALSE. Setting outlinePreferred ° d ONLN dÖ <(T (D Z7= TRUE makes a difference only for point sizes where a ° d ONLN dº T(˛ (Dr#bitmap font strike is present along ° d ONLN d‡( <4 Ï (P Z'with a 'sfnt' in the same family/style. ° d ONLN d@ <Lfi *[TrueType fonts might be preferable even for small point sizes if linearly scaled character ° d ONLN dc@fiL˛ (h¸widths ° d ONLN djL <Xõ (t ZCare more important than screen rendering: If the main purpose of a ° d ONLN d≠LõX˛ (tπprogram is preprint ° d ONLN d¡X <d ÷ (Ä Z!processing for a high-resolution ° d ONLN d‚X ÷d˛ )ö;output device, then outlinePreferred = TRUE may give better ° d ONLN d d <p Q (å Zline ° d ONLN d#d Qp˛ )Xlayout results on the printer, at the price of “not so great” type rendering on a 72 dpi ° d ONLN d|p <|8 (ò Z6screen. (An example for the conflict between linearly ° d ONLN d≤p8|˛ )¸(scaling TrueType and non-linearly scaled ° d ONLN d€| <à Ö (§ Zbitmap fonts is ° d ONLN dÎ| Öà˛ )IOHelvetica: StringWidth('Lilli') returns 19 for the 12-point bitmap font, and 15 ° d ONLN d;à <î Ò (∞ Z&for the 13-point size from TrueType!) ° d ONLN db† <¨ e * All this ° d ONLN dk† e¨˛ ))Oboils down to the recommendation stated initially: The user should be given the ° d ONLN dª¨ <∏ · (‘ Z%flexibility to decide whether to use ° d ONLN d‡¨ ·∏˛ )•:the existing bitmaps (using TrueType only for bigger point ° d ONLN d∏ <ƒ V (‡ Zsizes ° d ONLN d!∏ Vƒ˛ )Yand high-resolution printers), or to go with TrueType even if the result on the screen is ° d ONLN d{ƒ <– N (Ï Znot ° d ONLN dƒ N–˛ )Zoptimal. (By the way, it’s likely that TrueType development will substantially reduce this ° d ONLN d⁄– <‹ £ (¯ Zconflict in the future.)
° d ONLN dÛÙ <¬ *'7FontRec fontType field and determining monospaced fonts
° d ONLN d + < b * Written: ° d ONLN d 4 à ¨ )L1/13/92 ° d ONLN d < < Å (7 ZLast reviewed: ° d ONLN d K à ¶ )L8/1/92 ° d ONLN d R' <3
(O Z+How can I create a menu that contains only ° d ONLN d }'
3˛ )Œ0fixed width fonts? The FontRec record’s fontType ° d ONLN d Æ3 <? z ([ Zfield doesn’t ° d ONLN d º3 z?˛ )>Qcorrectly tell me if the font is fixed width as Inside Macintosh Volume V says it ° d ONLN d
? <K‘ (g ZUshould. All system fonts appear to have the same fontType regardless of whether they ° d ONLN d
c?‘K˛ (gÚ are fixed ° d ONLN d
mK <W+ (s Z6or proportional. Currently I test if the width of the ° d ONLN d
£K+W˛ )Ô,characters “m” and “i” are equal and if they ° d ONLN d
fonts like ° d ONLN d <ü <´ ¸ (« Z%Monaco or Courier don’t have the bit ° d ONLN d aü ¸´˛ )¿4set; so the meaning of this bit is just perverted to ◊ X◊
(Ï ZFont Manager Q&As (Ï5 ) of 8 ˇ¨ ◊# ˇ ˇˇˇˇ # ◊
IR , Times
. +6-Macintosh Technical Notes / 4 /˘
° d ONLN d ) *0nonsense—sorry! In addition, the fontType field ° d ONLN d 0 )⁄ )È*only is available for 'FONT's and 'NFNT's; ° d ONLN d [ ) 5V ( Q 6Eit does not exist in 'sfnt's, and you would have to check separately ° d ONLN d † )V 5⁄ ( Qt for the resource type of the ° d ONLN d Ω 5 A / ( ] 6font. ° d ONLN d √ M YF *?Your idea of comparing the widths of “m” and “i” (or any other ° d ONLN d MF Y⁄ ( ud characters which are extremely ° d ONLN d! Y e ( Å 65unlikely to have the same widths in a proportionally ° d ONLN dV Y e⁄ )˜*spaced font) is indeed the only reasonable ° d ONLN dÅ e q È ( ç 6,way of figuring out if a font is monospaced.
° d ONLN dÆ â òe *'3Getting global width table for a font specification
° d ONLN d‚ ò § > * Written: ° d ONLN dÎ ò d § à )L4/22/92 ° d ONLN dÛ § ∞ ] ( Ã 6Last reviewed: ° d ONLN d § d ∞ Ç )L8/1/92 ° d ONLN d º » Ø ( ‰ 6 What’s the fastest way to get ° d ONLN d' º Ø »⁄ )ó:the width table for a given font? FontMetrics is too slow, ° d ONLN db » ‘ U ( 6especially in ° d ONLN dp » U ‘⁄ )=Ucolor. Is there any other call that will get the global width table set up correctly? ° d ONLN dΔ ‘ ‡ ( ¸ 66That is all that we need from the call to FontMetrics. ° d ONLN d˝ ‡ Ï * * ___ ° d ONLN d ¯ ´ *OFontMetrics does not have much overhead in setting up the width table. It does ° d ONLN dP ¯´⁄ ( …a dummy ° d ONLN dX ) (, 6<DrawChar(' '); this is very rapidly transformed into a call ° d ONLN dî)⁄ (,G#to StdText, and StdText immediately ° d ONLN d∏ ¯ (8 6+calls StdTxMeas. The first thing StdTxMeas ° d ONLN d„ ¯ ⁄ )‡,does is to set up the input parameters for a ° d ONLN d ( § (D 6 FMSwapFont call and call it. ° d ONLN d- §(⁄ )å=FMSwapFont is the heart of the Font Manager, and does all the ° d ONLN dk( 4 Ä (P 6work. It comes back ° d ONLN d( Ä4⁄ )hDwith the FMOutput record, the font strike, and the width table. From ° d ONLN dƒ4 @2 (\ 6=there, FontMetrics derives the values it needs to bring back. ° d ONLN dL X … * You probably wouldn’t save much ° d ONLN d"L …X⁄ )±5more than 1/1000th of a second if, instead of calling ° d ONLN dXX dΔ (Ä 6WFontMetrics, you called FMSwapFont explicitly yourself—our only alternative suggestion. ° d ONLN d∞p | *-The Font Manager does quite a lot of caching ° d ONLN d›p |⁄ )ÿ/(up to 12 width tables), and managing the cache ° d ONLN d
| à 3 (§ 6takes ° d ONLN d| 3à⁄ )Ysome cycles, too. If there is nothing in the cache corresponding to the font request, the ° d ONLN dmà îJ (∞ 6@cache makes the call even slower than it would be without cache. ° d ONLN dƆ ¨ ƒ *#The next source of overhead is the ° d ONLN d—† ƒ¨⁄ )¨6Resource Manager. Looking for a specific font involves ° d ONLN d¨ ∏ (‘ 65going through the whole resource chain first for the ° d ONLN d=¨ ∏⁄ (‘>"FOND (if none is found, the search ° d ONLN d`∏ ƒ´ (‡ 6Rrestarts for a FONT), and then, based on the FOND’s font association table, for a ° d ONLN d≤∏´ƒ⁄ (‡…NFNT or ° d ONLN d∫ƒ – √ (Ï 6!'sfnt'. If no NFNT is found, the ° d ONLN d€ƒ √–⁄ )´4search restarts for a FONT, always through the whole ° d ONLN d– ‹ É (¯ 6resource chain. For a ° d ONLN d&– É‹⁄ )kDhuge resource fork like in the System file (and, maybe, also in your ° d ONLN dk‹ Ë Ω ( 6$application), the time spent in the ° d ONLN dè‹ ΩË⁄ )•8Resource Manager is not negligable—in particular, if you ° d ONLN d»Ë Ù¡ ( 6Whave add-ons in your system (such as INITs or 'cdev's) that patch out Resource Manager ° d ONLN d Ë¡Ù⁄ (flcalls, ° d ONLN d &Ù 8 ( 6;maybe several times, and usually slow it down considerably! ° d ONLN d b ¥ *REven in case this hurdle is overcome swiftly (after all, the Resource Manager has ° d ONLN d ¥ ¥⁄ (4“its own ° d ONLN d º $ „ (@ 6+caching scheme for optimization), the next ° d ONLN d Á „$⁄ )À2step necessarily takes some time, and, as you have ° d ONLN d
$ 0; (L 6@observed, especially on a color system: It consists of actually ° d ONLN d
Z$;0⁄ (LY!providing the bitmap for the font ° d ONLN d
|0 < U (X 6strike. If the ° d ONLN d
ã0 U<⁄ )=Sscreen depth is >1, this involves creating “synthetic” fonts for the correct screen ° d ONLN d
fl< H Ñ (d 6depth, to optimize text ° d ONLN d
˜< ÑH⁄ )lKdrawing. Also, if the font is an outline font, the first time a font strike ° d ONLN d CH T: (p 6@has to be rasterized is quite costly in terms of machine cycles. ° d ONLN d Ñ` l µ * Finally, the width table can be ° d ONLN d §` µl⁄ )ù;created; and, because of the scaling factors involved, this ° d ONLN d ‡l xÄ (î 6Jrequires 256 times some arithmetic which is known never to be fast enough. ° d ONLN d +Ñ ê *5All this certainly gives us an understanding for the ° d ONLN d `Ñê⁄ ))time it takes FMSwapFont (FontMetrics) to ° d ONLN d äê ú (∏ 65get the job done, but it does not solve your problem. ◊ 4◊˘
*46 ) of 8 (Ï£Font Manager Q&As ˇº ◊# ˇ ˇˇˇˇ # ◊
IR , Times
. +Z-Developer Support Center ( -Ê October 1992 / X /
° d ONLN d < ) ô ( E ZDepending on how ° d ONLN d ô )˛ )]Kpredictable the usage of fonts and width tables in your application is, you ° d ONLN d ] ) < 5 « ( Q Z might consider building kind ° d ONLN d z ) « 5˛ )ã?of a database of width tables beforehand, or along the way, and ° d ONLN d ∫ 5 < AŸ ( ] ZXuse this information directly from within your application. There is no shortcut at all ° d ONLN d 5Ÿ A˛ ( ]˜through ° d ONLN d A < M Ñ ( i Z
the Resource ° d ONLN d' A Ñ M˛ )HEManager to get at the font resources, and there is no shortcut within ° d ONLN dm M < Y Ê ( u Z"FMSwapFont, like not building the ° d ONLN dè M Ê Y˛ )™8font bitmaps. (To the best of my knowledge, the needbits ° d ONLN d» Y < e– ( Å ZRfield in the FMInput record does *not* have this effect.) The only obvious way to ° d ONLN d Y– e˛ ( ÅÓ get width ° d ONLN d$ e < q† ( ç ZMtables faster is to keep them around, and to extend manually the capacity of ° d ONLN dq e† q˛ ( çæthe Font Manager’s ° d ONLN dÑ q < } £ ( ô Zcache of width tables.
° d ONLN dõ ï < §l *'-SetFractEnable and recalculating width tables
° d ONLN d… § < ∞ b * Written: ° d ONLN d“ § à ∞ ¶ )L5/5/92 ° d ONLN dŸ ∞ < º Å ( ÿ ZLast reviewed: ° d ONLN dË ∞ à º ¶ )L8/1/92 ° d ONLN dÔ » < ‘m ( Z=Calling SetFractEnable seems to force the width tables to be ° d ONLN d, »m ‘˛ ( ã recalculated regardless of the ° d ONLN dK ‘ < ‡ ( ¸ ZVsetting of the low-memory global FractEnable. We’re calling this routine at a central ° d ONLN d° ‘ ‡˛ ( ¸Ë entry point ° d ONLN d≠ ‡ < Ïo ( Z<for any document, as it’s a document by document attribute. ° d ONLN dÈ ‡o Ï˛ (ç We then unconditionally call ° d ONLN d Ï < ¯p ( ZASetFractEnable(false) on exit back to the event loop, to be nice ° d ONLN dG Ïp ¯˛ (é to other applications. Calling ° d ONLN df ¯ < à ( Z SetFractEnable(false), seems ° d ONLN dÉ ¯ Ã˛ )ê>to trigger the recalculation even though FractEnable is false. ° d ONLN d¬ < ˆ (, Z'What’s the best way to get around this? ° d ONLN dÍ < N * ___ ° d ONLN dÓ( <4 W *Your ° d ONLN dÛ( W4˛ )Yobservation is correct. The SetFractEnable call stuffs the boolean parameter (as a single ° d ONLN dM4 <@] (\ Z;byte) into the low-memory global $BF4 and indiscriminately ° d ONLN dà4]@˛ (\{"invalidates the cached width table ° d ONLN d´@ <L∏ (h ZJby setting $B4C (LastSpExtra) to -1 (LongWord = Fixed). Obviously, it was ° d ONLN dı@∏L˛ (h÷not anticipated ° d ONLN dL <X ˝ (t Z*that SetFractEnable could be called quite ° d ONLN d/L ˝X˛ )¡5regularly with a parameter that often does not change ° d ONLN deX <dÙ (Ä Z^the previous setting. (By the way, the same observation applies to the SetFScaleDisable call). ° d ONLN dƒp <|N *9In your case, you may want to replace the SetFractEnable ° d ONLN d˝pN|˛ (òl$call by your own test of the boolean ° d ONLN d"| <àW (§ Z<(8-bit) in $BF4 (FractEnable), and call SetFractEnable only ° d ONLN d^|Wà˛ (§u$if the parameter passed is different ° d ONLN dÉà <î Ü (∞ Zfrom the value ° d ONLN díà Üî˛ )JIstored in $BF4. Note that Inside Macintosh Volume IV (page 32) explicitly ° d ONLN d‹î <†° (º ZNallows you to hack the $BF4 location directly, so it’s unlikely there are any ° d ONLN d*î°†˛ (ºøfuture compatibility ° d ONLN d?† <¨ w (» Z problems if ° d ONLN dK† w¨˛ );Kyou go your own way around the original SetFractEnable. The only additional ° d ONLN dó¨ <∏º (‘ ZHinformation you need is what’s mentioned above: The Font Manager always ° d ONLN dfl¨º∏˛ (‘⁄ checks $B4C ° d ONLN dÎ∏ <ƒ\ (‡ Z;(LastSpExtra) for -1 before doing anything with the global ° d ONLN d &∏\ƒ˛ (‡z!width table; if it finds ($B4C) = ° d ONLN d Hƒ <–# (Ï Z3LongInt(-1), it painfully rebuilds the width table. ° d ONLN d |‹ <Ë ≠ *Another comment: You ° d ONLN d ë‹ ≠˲ )qFdo not need to think of other applications when resetting FractEnable; ° d ONLN d ÿË <Ù … ( Z in a context switch to another ° d ONLN d ˜Ë …Ù˛ )ç>application, all low-memory globals are swapped anyway. Still, ° d ONLN d
6Ù < ò ( ZFthe above optimization of SetFractEnable probably is useful even when ° d ONLN d
|Ùò ˛ ( ∂you don’t call it any ° d ONLN d
í < (( Z.more systematically on exit to the event loop.
° d ONLN d
¡$ <3ã *'2Corrupted Macintosh font or font suitcase criteria "C W
° d ONLN d
Ù3 <? b * Written: ° d ONLN d
˝3 à? ¨ )L6/19/92 "R W ° d ONLN d ? <K Å (g ZLast reviewed: ° d ONLN d ? àK ¨ )L9/15/92 "^ W "j W ° d ONLN d W <c ( Z*I would like to be able to detect whether ° d ONLN d FWc˛ )»2a font suitcase is corrupted when it is opened and "v W ° d ONLN d yc <o (ã Z[whether any of the fonts in it are corrupted before any of the fonts are used. I know that ° d ONLN d ‘co˛ (ãthe "Ç W ° d ONLN d ÿo <{¬ (ó ZTFinder is able to do this, and I was wondering if Apple gives out this information. ° d ONLN d ,o¬{˛ (ó‡
My program "é W ° d ONLN d 7{ <á ¿ (£ Zwill only run under System ° d ONLN d R{ ¿á˛ )Ñ@7.0 if that helps. Any information that you can give me would be "ö W ° d ONLN d ìá <ì ò (Ø Zgreatly appreciated. "¶ W ° d ONLN d ®ì <ü N * ___ "≤ W "æ W ◊ X◊
*1Font Manager Q&As (Ï7 ) of 8 ˇ Ê ◊# ˇ ˇˇˇˇ # ◊
IR , Times
. +6-Macintosh Technical Notes / 4 /˘
° d ONLN d ) ‹ *)The Finder and the type architecture are ° d ONLN d ) ‹ )⁄ )ƒ5living things; the definition of what is and is not a " < 3 ° d ONLN d _ ) 5 Ì ( Q 6,damaged suitcase can change from release to ° d ONLN d ã ) Ì 5⁄ )’/release of system software. However, any of the " H 3 ° d ONLN d ª 5 As ( ] 6Gfollowing conditions makes System 7.0 report the suitcase as “damaged”: " T 3 " ` 3 ° d ONLN d M Y *0• More than eight FONDs reference the same font. " l 3 " x 3 ° d ONLN d4 e q  *,• A new stand-alone object can’t be created ° d ONLN d` e  q⁄ )Õ4for a font icon. The usual cause of this is that two " Ñ 3 ° d ONLN dï q }Ö ( ô 6LFONDs have the same name for the first 31 characters, and the Finder thinks ° d ONLN d· qÖ }⁄ ( ô£there’s already an " ê 3 ° d ONLN dÙ } âì ( • 6Nicon in that window with the same name. (Two icons in the same directory with ° d ONLN dB }ì â⁄ ( •±
the same name " ú 3 ° d ONLN dP â ï { ( ± 6is a sign of damage.) " ® 3 " ¥ 3 ° d ONLN df ° ≠ à *• There must be at least ° d ONLN d ° à ≠⁄ )pIone font association table entry, and the table can’t go past the logical " ¿ 3 ° d ONLN d… ≠ π v ( ’ 6end of the resource. " à 3 " ÿ 3 ° d ONLN dfi ≈ —ë *N• The first resource name in the map must not be zero-length (which is a test ° d ONLN d, ≈ë —⁄ ( ÌØfor some older " ‰ 3 ° d ONLN d; — › Ø ( ˘ 6!third-party corrupted suitcases). " 3 " ¸ 3 ° d ONLN d] È ı Ø * • The FOND must have a name. " 3 " 3 ° d ONLN dz
q *• The FOND must ° d ONLN dä q
⁄ )YMhave a valid character range—the first character has to be less than the last " 3 ° d ONLN dÿ
H (5 6>character—unless it is a "dummy" FOND (created on the fly for ° d ONLN d
ONLN f ˛ † å ° d 1drw2 … -·_ Ä ˇˇˇˇˇˇ è ° ñ x ° d drw2 : ° d drw2 : $ ° d 4drw2 : ° ö ˇ˙ ó@ † ò , Times
. R… R… +]BNew Technical Notes † ô ° d drw2 : °„ † ó ° d 1drw2 eÙ Ä ˇˇˇˇˇˇ P ° ñ x ° d drw2 : ° d drw2 : $ ° d 4drw2 : ° ö ˇ˚Ä E¿ † ò
( {ïDeveloper Support † ô ° d drw2 : °„ † ó ° d `drw2 - Ô ˇˇˇˇˇˇ K Ô - Z f f Z ° d 1drw2 ¿˙È ˇˇˇˇˇˇ K ° ñ x ° d drw2 : ° d drw2 : $ ° d 4drw2 : 0 ° ö ˇÙ Ä † ò
0 ( UÔ † ô ° d drw2 : °„ † ó ° d 1drw2 ÔÊ˙ ˇˇˇˇˇˇ ° ñ x ° d drw2 : ° d drw2 : $ ° d 4drw2 : ° ö ˇ˝Ä † ò
+& ® † ô ° d drw2 : °„ † ó ° d 1drw2  -¯ y ˇˇˇˇˇˇ ° ñ x ° d drw2 : ° d drw2 : $ ° d 4drw2 : ° ö ˇ˚Ä % † ò
( Z \ Macintosh † ô ° d drw2 : °„ † ó † ç ° d drw2 D † É
IR . ° d ONLN d z < ç/ ( ß Z Fonts and the Script Manager
° d ONLN d å < õ Z *Text ° d ONLN d # åf õ˛ ( ∑ÑM.TE.FontsAndScripts
° d ONLN d 8 ß < ≥ q ( œ Z Written by: ° d ONLN d D ß Ñ ≥
)HJohn Harvey & Peter Edberg ° d ONLN d _ ßÕ ≥˛ ( œÎ June 1989 ° d ONLN d i ø < À û ( Á ZThis Technical Note ° d ONLN d } ø û À˛ )bGdescribes how the Script Manager uses the font family ID to determine a ° d ONLN d ≈ À < ◊ s ( Û Z script code. X ° d ONLN d “ Ò < ˝ k *&
The traps ,
Courier ° d ONLN d ‹ k ¸ ∏ )/ _FontScript ° d ONLN d Á Ò ∏ ˝ ø )M, ° d ONLN d È ø ¸ ) _IntlScript ° d ONLN d Ù Ò ˝ )M, ° d ONLN d ˆ Ò ˝( )and ° d ONLN d ˙ ( ¸| ) _Font2Script ° d ONLN d Ò| ˝˛ )T all use a font family ID to ° d ONLN d# ˝ < í (% ZHdetermine the script interface system code that they return. This Note ° d ONLN dk ˝í ˛ (%∞describes the process, ° d ONLN dÇ <k (1 Z:the way the Script Manager renumbers the Chicago font for ° d ONLN dº k˛ (1ânon-Roman systems, and the ° d ONLN d◊ <!F (= Z9equation for calculating Script IDs from font family IDs. ° d ONLN d. <: W *On a ° d ONLN d. W: „ )Roman system the Chicago ° d ONLN d/- „9
)å'FOND' ° d ONLN d5.
:˛ )*/ is numbered zero, but this causes no confusion ° d ONLN de: <F Ù (b Z(since Chicago is also the system font. ° d ONLN dç: ÙF˛ )∏2Non-Roman systems must renumber Chicago so that it ° d ONLN d¿G <S ˝ (o Z'will not interfere with the mapping of ° d ONLN dÁF ˝R^ )¡
Inside Macintosh ° d ONLN dQl öxü )Q5, Volume V-293, The Script Manager, the descriptions ° d ONLN dÜlüx≠ (îΩof ° d ONLN dâk≠w˙ ) _FontScript ° d ONLN dîl˙x˛ )M, ° d ONLN dñx <Ñ â (° Z _IntlScript ° d ONLN d°y âÖ ¶ )M, and ° d ONLN dßx ¶Ñ ˙ ) _Font2Script ° d ONLN d≥y ˙Ö„ )T3 state that the current font identification number ° d ONLN dÊy„Ö˛ )È(e.g., ° d ONLN dÌÖ <ë f (Æ Z'FOND' ° d ONLN dÛÜ fím )*9 ID) is used to calculate the correct script code. The ° d ONLN d,Ümí˛ (Æã equation for calculating script ° d ONLN dLì <ü t (ª Z codes from ° d ONLN dWí tû û )8'FOND' ° d ONLN d]ì ûü Ù )* IDs is as follows:
° d ONLN dq´ ∞∂n +&script =((FONDid - $4000) DIV 512) + 1
° d ONLN dò¡ <Õi (È Z9For a specific example, consider the Kyoto font which is ° d ONLN d—¡iÕ˛ (Èá one of the fonts included in ° d ONLN dÓŒ <⁄ á (ˆ ZKanjiTalk. Its ° d ONLN d˛Õ ០± )K'FOND' ° d ONLN dŒ ±⁄* )* ID is 16385. Plugging ° d ONLN d Œ*⁄˛ )y+that value into the equation above, we get: ° d ONLN dH⁄ <Êm ( Z?script = ((16385-16384) DIV 512) +1. Which results in a value ° d ONLN dá⁄mÊ˛ (ã of one, the script code for the ° d ONLN dßÊ <Ú õ ( ZKanji script system. ° d ONLN dº˛ <
∏ *Note that this means that ° d ONLN d÷˛ ∏
˛ )|?script systems other than Roman can only have 512 separate font ° d ONLN d
<g (2 Z<families. Furthermore, Roman font families (FOND) must not ° d ONLN dR
g˛ (2Ö have an ID greater than 16383, ° d ONLN dq <# P (? Zand ° d ONLN du P" z )'FOND' ° d ONLN d{ z#í )*7 ID 16383 is reserved for Chicago on non-Roman systems.
° d ONLN d≥; <J › (f ZSo How Do They Work?
° d ONLN d»V <b â * _FontScript ° d ONLN d”W âc ê )M, ° d ONLN d’V êb › ) _IntlScript ° d ONLN d‡W ›c ¯ )M, and ° d ONLN dÊV ¯bL ) _Font2Script ° d ONLN dÚWLcl )T begin ° d ONLN d˘Wlc˛ ) by setting two Script Manager ° d ONLN dd <p h (å Z globals, ° d ONLN d c ho í ),Forced ° d ONLN d&d íp Ø )* and ° d ONLN d+c Øo ‡ ) Default ° d ONLN d2d ‡pM )1 to false. Then the ° d ONLN dGdMp– )mtwo special font family ( ° d ONLN d`c–o˙ )É'FOND' ° d ONLN dfd˙p˛ )*) ° d ONLN dhp <|á (ò ZCnumbers zero and one are mapped to the System and Application font. ◊ X◊
*T Fonts and the Script Manager (Ï1 ) of 4 ˇ ° ¿Ù%%DSIDICT:_cv
currentdict /bu known {bu}if
userdict /_cv known not{userdict /_cv 30 dict put}if
_cv begin
/bdf{bind def}bind def
currentscreen/cs exch def/ca exch def/cf exch def
/setcmykcolor where{/setcmykcolor get /cvcmyk exch def}{/cvcmyk{1 sub 4 1 roll 3{3 index add neg dup 0 lt{pop 0}if 3 1 roll}repeat setrgbcolor pop}bdf }ifelse
/ss{//cf //ca //cs setscreen}bdf
/stg{ss setgray}bdf
/strgb{ss setrgbcolor}bdf
/stcmyk{ss cvcmyk}bdf
/min1{dup 0 eq{pop 1}if}bdf
end
currentdict /bn known {bn}if
† øé ◊# ˇ ˇˇˇˇ # ◊
IR , Times
. +6-Macintosh Technical Notes / 4 /˘
° d ONLN d * G * Next the ,
Courier ° d ONLN d G ) q )/'FOND' ° d ONLN d q * v )* ° d ONLN d v *v )5ID is tested to see if it is an international font. ° d ONLN d E v )√ ( Fî _FontScript ° d ONLN d P √ *⁄ )M and ° d ONLN d U * 6 e ( S 6 _IntlScript ° d ONLN d ` + e 7 i )M ° d ONLN d a + i 7
À () 6+script is installed and enabled. If it is ° d ONLN d˙ À
W )≥ not; Roman is returned, and ° d ONLN d W Å )åForced ° d ONLN d Å
⁄ )* is set to false and ° d ONLN d1
I (6 6Default ° d ONLN d8 I â )1 is set to true.
° d ONLN dI2 A « (] 6What’s This Forced Stuff?
° d ONLN dcN Z π * Two Script Manager globals, ° d ONLN dM πY ¯ )° fontForce ° d ONLN dàN ¯Z )? and ° d ONLN dçMYX )! intlForce ° d ONLN dñNXZ⁄ )?, are flags that support ° d ONLN dØ[ g à (É 6compatibility. Turning ° d ONLN d«Z àf « )p fontForce ° d ONLN d–[ «gK )? on will cause Roman fonts ° d ONLN dÎ[Kg⁄ )Ñ to be interpreted as belonging ° d ONLN d
g s÷ (è 6`to the system script. This provides compatibility for applications that hard-code font numbers. ° d ONLN dk ãH *;For example, the Arabic script interface system provides a ° d ONLN d¶Hã⁄ (ßfcdev which lets a user turn ° d ONLN d¬ã ó W (¥ 6 fontForce ° d ONLN dÀå Wò fl )? on. When a user does this, ° d ONLN dËå flò⁄ )à1any Roman fonts will be mapped to an Arabic font. ° d ONLN dò §q (¿ 6NNote this is only a partially effective measure since the user still does not ° d ONLN diòq§⁄ (¿èhave complete control ° d ONLN d§ ∞ L (à 6 over fonts. ° d ONLN dãΩ … à *'It should also be noted that if a user ° d ONLN d≤Ω Ã… „ )¥sets ° d ONLN d∑º „»" ) fontForce ° d ONLN d¿Ω"…⁄ )?% on via the cdev, values returned for ° d ONLN dÊ ÷ ë (Ú 6fonts with family IDs in ° d ONLN dˇ ë÷E )y the range $0002 to $3FFF (Roman ° d ONLN d …E’o )¥'FOND' ° d ONLN d% o÷⁄ )* ID range) may vary. ° d ONLN d;÷ ‚X (˛ 6DThis is not a good feature for applications that allow mixed text. ° d ONLN d÷X‚⁄ (˛vTo avoid this problem, an ° d ONLN dô„ Ô § ( 6application can turn the ° d ONLN d≤‚ §Ó „ )å fontForce ° d ONLN dª„ „Ôr )? flag off before calling ° d ONLN d‘‚rÓΔ )è _Font2Script ° d ONLN d‡„ΔÔ– )T ° d ONLN d·„–Ô⁄ )
or ° d ONLN d‰Ô ˚ e ( 6 _FontScript ° d ONLN dÔ e¸Ω )ML. The flag value should be saved before turning it off, and restored later. ° d ONLN d< / (1 6The ° d ONLN d@ / n ) intlForce ° d ONLN dI n )? flag determines how the call ° d ONLN dgC )ñ IUGetIntl ° d ONLN dp C⁄ )? behaves. If this flag is on, ° d ONLN dè ! W (> 6 IUGetIntl ° d ONLN dò W"L )?0 will always return the international resources ° d ONLN d»L"P )ı( ° d ONLN d…P!z )'itlx' ° d ONLN dœz"ß )* where ° d ONLN d÷ß!Æ )-x ° d ONLN d◊Æ"⁄ ) is 0-2) ° d ONLN d‡# / „ (K 6*corresponding to the system script. When ° d ONLN d
" „." )À intlForce ° d ONLN d #"/V )?
is off, the ° d ONLN d #V/⁄ )4 font in the current port will ° d ONLN d >/ ; Î (W 6)be used to determine which international ° d ONLN d g/ Î;⁄ )”.resources will be returned. This flag lets an ° d ONLN d ñ; Gr (c 6Lapplication control what date formats, sorting routines, etc. will be used. ° d ONLN d „S _ „ *+For that reason, before calling any of the ° d ONLN d
S „_⁄ )À5international utility routines or using the binary to ° d ONLN d
D` l (à 64decimal routines, an application should verify that ° d ONLN d
x_k7 )ÓthePort ° d ONLN d
`7lN )1 and ° d ONLN d
Ñ_Nk∑ )thePort^.txFont ° d ONLN d
ì`∑l⁄ )i are set ° d ONLN d
úm y i (ï 6correctly, or that ° d ONLN d
Øl ix ® )Q intlForce ° d ONLN d
∏m ®y Ú )? is set properly. ◊ 4◊˘
(Ï 62 ) of 4 (ÏÇ Fonts and the Script Manager ˇ!Ë ◊# ˇ ˇˇˇˇ # ◊
IR , Times
. +Z-Developer Support Center ( -Û June 1989 / X /
° d ONLN d ) < 5 æ ( Q ZLet’s Look at a Picture ° d ONLN d B < N Ó *&The flowchart in Figure 1 illustrates ° d ONLN d > B Ó NA )≤the operation of ,
° d ONLN d ¬[ «gr (É Â Figure 1–Operation Flowchart ◊ X◊
(Ï Z Fonts and the Script Manager (Ï3 ) of 4 ˇŒ ◊# ˇ ˇˇˇˇ # ◊
IR , Times
. +6-Macintosh Technical Notes / 4 /˘
° d ONLN d ) 5 Ç *$Further Reference: T 4 T˘ ° d ONLN d 6 * B . +
• ° d ONLN d 6 < B ç )Inside Macintosh ° d ONLN d % 6 ç B )Q3, Volume I-493, The International Utilities Package ° d ONLN d Y B * N . ( j H• ° d ONLN d [ B < N ç )Inside Macintosh ° d ONLN d k B ç N> )Q", Volume V-293, The Script Manager ° d ONLN d é N * Z . ( v H• ° d ONLN d ê N < Z ç )Inside Macintosh ° d ONLN d † N ç ZÉ )Q3, Volume V-287, The International Utilities Package ◊ 4◊˘
(Ï 64 ) of 4 (ÏÇ Fonts and the Script Manager ˇí ◊# ˇ ˇˇˇˇ # ◊ † Ç
/ Z Å#
0Ià:µú9 " { ˇˇˇˇˇˇˇˇ # † ƒ ° d
ONLN f ˛ † å ° d 1drw2 … -·_ Ä ˇˇˇˇˇˇ è ° ñ x ° d drw2 : ° d drw2 : $ ° d 4drw2 : ° ö ˇ˙ ó@ † ò , Times
. R… R… +]BNew Technical Notes † ô ° d drw2 : °„ † ó ° d 1drw2 eÙ Ä ˇˇˇˇˇˇ P ° ñ x ° d drw2 : ° d drw2 : $ ° d 4drw2 : ° ö ˇ˚Ä E¿ † ò
( {ïDeveloper Support † ô ° d drw2 : °„ † ó ° d `drw2 - Ô ˇˇˇˇˇˇ K Ô - Z f f Z ° d 1drw2 ¿˙È ˇˇˇˇˇˇ K ° ñ x ° d drw2 : ° d drw2 : $ ° d 4drw2 : 0 ° ö ˇÙ Ä † ò
0 ( UÔ † ô ° d drw2 : °„ † ó ° d 1drw2 ÔÊ˙ ˇˇˇˇˇˇ ° ñ x ° d drw2 : ° d drw2 : $ ° d 4drw2 : ° ö ˇ˝Ä † ò
+& ® † ô ° d drw2 : °„ † ó ° d 1drw2  -¯ y ˇˇˇˇˇˇ ° ñ x ° d drw2 : ° d drw2 : $ ° d 4drw2 : ° ö ˇ˚Ä % † ò
( Z \ Macintosh † ô ° d drw2 : °„ † ó † ç ° d drw2 D † É
IR . ° d ONLN d n < Å/ ( õ ZInternational Resource Q&As
° d ONLN d Ä < è Z *Text ° d ONLN d " Äo è˛ ( ´çM.TX.IntlRsrc.Q&As
° d ONLN d 5 õ < ß t ( √ Z Revised by: ° d ONLN d A õ Ñ ß ˇ )HDeveloper Support Center ° d ONLN d Z õæ ߲ ( √‹ October 1992 ° d ONLN d g ß < ≥ q ( œ Z Written by: ° d ONLN d s ß Ñ ≥ ˇ )HDeveloper Support Center ° d ONLN d å ßæ ≥˛ ( œ‹ October 1990 ° d ONLN d ô ø < À ⁄ ( Á Z This Technical Note contains a ° d ONLN d ∏ ø ⁄ À˛ )û9collection of Q&As relating to a specific topic—questions ° d ONLN d Ú À < ◊† ( Û ZGyou’ve sent the Developer Support Center (DSC) along with answers from ° d ONLN d9 À† ◊˛ ( Ûæthe DSC engineers. ° d ONLN dL ◊ < „ u ( ˇ Z
While DSC ° d ONLN dV ◊ u „˛ )9Lengineers have checked the Q&A content for accuracy, the Q&A Technical Notes ° d ONLN d£ „ < Ô q ( Z don’t have ° d ONLN dÆ „ q Ô˛ )5Qthe editing and organization of other Technical Notes. The Q&A function is to get ° d ONLN d Ô < ˚ Ÿ ( Z new technical information and ° d ONLN d Ô Ÿ ˚˛ )ù6updates to you quickly, saving the polish for when the ° d ONLN dU ˚ < (# Z,information migrates into reference manuals. ° d ONLN dÇ < k *:Q&As are now included with Technical Notes to make access ° d ONLN dºk ˛ (;â to technical updates easier for ° d ONLN d‹ <+. (G Z/you. If you have comments or suggestions about ° d ONLN d .+˛ )Ú*Q&A content or distribution, please let us ° d ONLN d6+ <7 \ (S Zknow ° d ONLN d;+ \7˛ ) Iby sending an AppleLink to DEVFEEDBACK. Apple Partners may send technical ° d ONLN dÖ7 <Ci (_ Z9questions about Q&A content to DEVSUPPORT for resolution. ° d ONLN døO <[« *NNew Q&As and Q&As revised this month are marked with a bar in the side margin. "n Ü XÜ
° d ONLN dÄ <èâ *41Determining the language being used to enter text
° d ONLN d@è <õ b * Written: ° d ONLN dIè àõ ≤ )L11/20/90 ° d ONLN dRõ <ß Å (√ ZLast reviewed: ° d ONLN daõ àß ¶ )L8/1/92 ° d ONLN dh≥ <ø H (€ ZIs ° d ONLN dk≥ Hø˛ ) Xthere a way to tell what language is being used on the Macintosh? I know how to find the ° d ONLN dƒø <ÀÊ (Á Z[script and other international items, but the language being spoken would be a very useful ° d ONLN d øÊÀ˛ (Áthing ° d ONLN d%À <◊ g (Û Zto know. ° d ONLN d.◊ <„ N * ___ ° d ONLN d2Ô <˚¡ *MIt depends on what you mean by “language.” It’s impossible to determine what ° d ONLN dÔ¡˚˛ (fl language the ° d ONLN då˚ < S (# Zuser ° d ONLN dë˚ S˛ )Xis typing in without doing a high-level analysis of what is being typed, as you probably ° d ONLN dÍ < [ (/ Zknow. ° d ONLN d <+ m *One way ° d ONLN d¯ m+˛ )1Lthat’s been suggested in the past is to check on the current KCHR by calling ° d ONLN dE+ <7è (S ZBGetScript with an smScriptKeys verb. This returns the resource ID ° d ONLN dá+è7˛ (S≠of the currently active ° d ONLN dü7 <C· (_ ZPKCHR. All international systems come with a U.S. KCHR and possibly others, such ° d ONLN dÔ7·C˛ (_ˇas the ° d ONLN dˆC <O‚ (k ZNRomaji and Kana KCHRs in the Japanese systems and the alternative Roman KCHRs ° d ONLN dDC‚O˛ (k in the ° d ONLN dKO <[≠ (w ZKvarious German and French systems. The thought was that the user will most ° d ONLN dñO≠[˛ (wÀlikely choose the ° d ONLN d®[ <gó (É ZDU.S. KCHR to type in English, and choose the French KCHR to type in ° d ONLN dÏ[óg˛ (ɵFrench. One problem ° d ONLN d g <s9 (è Z:with this is that it isn’t necessarily true. You can type ° d ONLN d:g9s˛ )˝$English with the French KCHR and you ° d ONLN d_s <Ö (õ Z?can type French with the U.S. KCHR, and many people do. A much ° d ONLN dûsÖ˛ (õ£larger problem is that the ° d ONLN dπ <ã\ (ß Z;KCHR IDs aren’t standardized within a script system range. ° d ONLN dÙ\ã˛ (ßz Because Apple defines a range of ° d ONLN d ã <ó è (≥ Zresource IDs for ° d ONLN d &ã èó˛ )SLeach script system for the international resources, you can tell what script ° d ONLN d só <£ú (ø ZAsystem a KCHR is for, and you can even match up the KCHR ID with ° d ONLN d ¥óú£˛ (ø∫the standard KCHR ◊ X◊
userdict /_cv known not{userdict /_cv 30 dict put}if
_cv begin
/bdf{bind def}bind def
currentscreen/cs exch def/ca exch def/cf exch def
/setcmykcolor where{/setcmykcolor get /cvcmyk exch def}{/cvcmyk{1 sub 4 1 roll 3{3 index add neg dup 0 lt{pop 0}if 3 1 roll}repeat setrgbcolor pop}bdf }ifelse
/ss{//cf //ca //cs setscreen}bdf
/stg{ss setgray}bdf
/strgb{ss setrgbcolor}bdf
/stcmyk{ss cvcmyk}bdf
/min1{dup 0 eq{pop 1}if}bdf
end
currentdict /bn known {bn}if
† øË ◊# ˇ ˇˇˇˇ # ◊
IR , Times
. +6-Macintosh Technical Notes / 4 /˘
° d ONLN d )£ *RIDs that Apple defines, but there’s nothing wrong with someone creating their own ° d ONLN d R £ )⁄ ( E¡KCHR and ° d ONLN d [ ) 5 Ë ( Q 6,giving it any ID they want, as long as it’s ° d ONLN d á ) Ë 5⁄ )–1in the proper range for the script system they’ve ° d ONLN d π 5 A fi ( ] 6/written it for. If that’s the currently active ° d ONLN d Ë 5 fi A⁄ )Δ2KCHR, its resource ID tells you what script system ° d ONLN d A M¢ ( i 6Vit’s for, but it won’t tell you anything about what language it was intended for. For ° d ONLN dq A¢ M⁄ ( i¿ this reason, ° d ONLN d~ M Y º ( u 6 this method is frowned upon now. ° d ONLN dü e q_ *HIn fact, there really is no reliable way of knowing the language that’s ° d ONLN dÁ e_ q⁄ ( ç}being used. The best you ° d ONLN d q }à ( ô 6[can do currently is to find out what the system is localized for. This is done by grabbing ° d ONLN d[ qà }⁄ ( ôÍthe ° d ONLN d_ } â i ( • 6vers resource ID ° d ONLN dp } i â⁄ )QL1 from the System file. In this resource is what was called the country code ° d ONLN dΩ â ïà ( ± 6](the term “country code” is obsolete, in favor of “region code”) which indicates what region ° d ONLN d âà ï⁄ ( ±Íthe ° d ONLN d ï °x ( Ω 6Fsystem is localized for. These region codes are defined in Packages.p ° d ONLN dd ïx °⁄ ( Ωñin MPW, and have ° d ONLN du ° ≠ Ô ( … 6,names like verUS and verFrance and the like. ° d ONLN d¢ π ≈∞ *JThere’s another way that you might want to consider. One of the GetScript ° d ONLN dÏ π∞ ≈⁄ ( ·Œverbs is ° d ONLN dı ≈ — † ( Ì 6smScriptLang. This returns ° d ONLN d ≈ † —⁄ )à@the language code of the specified script system for the current ° d ONLN dQ — › A ( ˘ 6system. ° d ONLN dY — A ›⁄ ))QIf you pass smRoman as the script code to GetScript, it’ll return langFrench on a ° d ONLN d´ › È º ( 6 French system, langGerman on ° d ONLN d» › º È⁄ )§1a German system, langEnglish on a U.S. or U.K. or ° d ONLN d˙ È ıî ( 6NAustralian system, and so forth. If you pass smJapanese as the script code to ° d ONLN dH Èî ı⁄ (≤GetScript, it’ll ° d ONLN dY ı ’ ( 6]return langJapanese. Interestingly, if you pass smRoman as the script code to GetScript when ° d ONLN d∂ ı’⁄ ( Ûa ° d ONLN d∏
ô () 6Japanese script system is ° d ONLN d“ ô
⁄ )Å?running, it’ll return langEnglish. All non-Roman script systems ° d ONLN d
2 (5 65return langEnglish if you pass smRoman as the script ° d ONLN dG
2⁄ (5P code to GetScript. The language ° d ONLN dg %± (A 6Sconstants are in Language.p in MPW. You’ll probably what to combine this GetScript ° d ONLN d∫±%⁄ (Aœ call with ° d ONLN dƒ% 1î (M 6Ua call to GetEnvirons to find out what the currently active script is. It might look ° d ONLN d%î1⁄ (M≤something like ° d ONLN d(1 = , (Y 6this: ,
Courier
° d ONLN d.I T ˛ *.(* Get the currently-active keyboard script *) ° d ONLN d]S ^ Ù *
,keyboardScript := GetEnvirons (smKeyScript); ° d ONLN däg rb *B(* Now get the language that the keyboard script corresponds to *) ° d ONLN dÕq |5 *
° d ONLN dá ì Æ * In summary, there’s no system ° d ONLN d%á Æì⁄ )ñ@support for retrieving the language that the user is typing, nor ° d ONLN dfì ü« (ª 6\is there any reliable support for retrieving the language related to any KCHR. But, you can ° d ONLN d¬ì«ü⁄ (ªÂfind ° d ONLN d«ü ´ p (« 6the region code of ° d ONLN d⁄ü p´⁄ )XKthe active system, and you can find the language associated with the active ° d ONLN d &´ ∑I (” 6Ascript. Hopefully, that’s enough information to be useful to you.
° d ONLN d hœ fie *'2RelString & EqualString vs International Utilities
° d ONLN d õfi Í > * Written: ° d ONLN d §fi dÍ à )L1/25/91 ° d ONLN d ¨Í ˆ ] ( 6Last reviewed: ° d ONLN d ªÍ dˆ Ç )L8/1/92 ° d ONLN d ¬ 5 (* 6What ° d ONLN d « 5⁄ ) Ris the difference between RelString and the EqualString? What does DTS suggest its ° d ONLN d
à (6 6NMacintosh developers use when sorting? Or do you suggest having an option for ° d ONLN d
hÃ⁄ (6Íthe ° d ONLN d
l & l (B 6international sort? ° d ONLN d
Ä& 2 * * ___ ° d ONLN d
Ñ> J *6RelString and EqualString are mainly intended for the ° d ONLN d
∫> J⁄ (f>#File Manager. The File Manager uses ° d ONLN d
fiJ V∂ (r 6Pthem for quick-and-dirty string comparison so that it knows how to return files ° d ONLN d .J∂V⁄ (r‘ordered ° d ONLN d 6V b ê (~ 6alphabetically when you ° d ONLN d NV êb⁄ )xCuse an indexed File Manager routines and so that it can detect file ° d ONLN d íb n5 (ä 68name collisions. Beyond that, RelString and EqualString ° d ONLN d b5n⁄ (äS"aren’t localizable and they’re not ° d ONLN d Ìn z K (ñ 6 extensible. ° d ONLN d ˘Ü í≠ *WThe International Utilities string comparison routines are localizable and extensible. ° d ONLN d PÜ≠í⁄ (ÆÀThey use ° d ONLN d Yí û ï (∫ 6information in the active ° d ONLN d sí ïû⁄ )}@'itl2' resource to determine how the characters are sorted. Most ° d ONLN d ¥û ™ E (Δ 6
localized ° d ONLN d æû E™⁄ )-Osystems come with their own 'itl2' resource, and so string comparisons are done ◊ 4◊˘
. +Z-Developer Support Center ( -Ê October 1992 / X /
° d ONLN d < )Ê ( E Z^correctly for the region that the system is localized for. RelString and EqualString stay the ° d ONLN d ^ Ê )˛ ( Esame ° d ONLN d c ) < 5J ( Q Z8for all these regions, and so you’ll probably find some ° d ONLN d õ )J 5˛ ( Qh#cases in which strings are compared ° d ONLN d ø 5 < A ≈ ( ] Z incorrectly by these routines. ° d ONLN d fi M < Y} *?One important place where RelString and EqualString don’t work ° d ONLN d M} Y˛ ( uõvery well is with the new ° d ONLN d7 Y < e ã ( Å Zcharacters in the ° d ONLN dI Y ã e˛ )OJextended Macintosh character set. When the LaserWriter was introduced, the ° d ONLN dî e < q ∑ ( ç ZLaserWriter fonts used ° d ONLN d´ e ∑ q˛ ){9the extended Macintosh character set which added many new ° d ONLN d q < } ( ô Z-characters, including several new upper-case ° d ONLN d q }˛ )€0characters with diacriticals. In system software ° d ONLN dC } < â∏ ( • ZJversion 6.0.4, the International Utilities were updated to take advantage ° d ONLN dç }∏ Ⲡ( •÷ of these new ° d ONLN dö â < ï ˙ ( ± Z(characters. For example, the upper case ° d ONLN d¬ â ˙ ï˛ )æ6“E” with a grave accent first appeared in the extended ° d ONLN d˘ ï < °ú ( Ω ZGMacintosh character set. With 6.0.4, the lower and upper case “E” with ° d ONLN d@ ïú °˛ ( Ω∫a grave accent were ° d ONLN dT ° < ≠ Ë ( … Z"considered to be equal in primary ° d ONLN dv ° Ë ≠˛ )¨5ordering, and unequal in secondary ordering, which is ° d ONLN d¨ ≠ < πû ( ’ ZKcorrect. But RelString and EqualString, even today, still think in the old ° d ONLN d˜ ≠û π˛ ( ’ºMacintosh character ° d ONLN d π < ≈È ( · ZXset, so they think that lower and upper case “E” with a grave accent have nothing to do ° d ONLN dc πÈ ≈˛ ( ·with ° d ONLN dh ≈ < — – ( Ì Z!each other, and that’s not right. ° d ONLN dä › < Èß *IBecause the RelString and EqualString algorithms are more crude than the ° d ONLN d” ›ß È˛ (≈string comparison ° d ONLN dÂ È < ı∑ ( ZNroutines in the International Utilities, RelString and EqualString should win ° d ONLN d3 È∑ ı˛ (’races with the ° d ONLN dB ı < { ( ZInternational ° d ONLN dP ı {˛ )?KUtilities string comparison routines hands down. The File Manager uses them ° d ONLN dú <
ø () ZPpartly for this reason, and partly because RelString and EqualString don’t need ° d ONLN dÏø
˛ ()›
access to the ° d ONLN d˙
<√ (5 ZM'itl2' resource, which is usually pretty big. Normally, File Manager sorting ° d ONLN dG
√˛ (5·isn’t critical ° d ONLN dV <% d (A Zanyway ° d ONLN d] d%˛ )(Ybecause it’s either irrelevant, or it can easily be cleaned up by using the International ° d ONLN d∑% <1 (M ZSUtilities string comparison routines. The Standard File package, for example, uses ° d ONLN d
%1˛ (Mthe ° d ONLN d1 <=Ω (Y ZUInternational Utilities string comparison routines to order file and folder names in ° d ONLN dc1Ω=˛ (Y€its list so that ° d ONLN dt= <I{ (e ZGthe list is ordered correctly regardless of the system it’s running on. ° d ONLN dºU <a ] *X-Ref: ° d ONLN d√a <mo * =Inside Macintosh Volume VI, page 14-82, “The 'itlm' Resource”
° d ONLN dy <àè */Macintosh PRAM’s MachineLocation dlsDelta field
° d ONLN d1à <î b * Written: ° d ONLN d:à àî ¨ )L1/25/91 ° d ONLN dBî <† Å (º ZLast reviewed: ° d ONLN dQî à† ¶ )L8/1/92 ° d ONLN dX¨ <∏— (‘ ZRHow is the dlsDelta field in PRAM’s time zone MachineLocation record used and set? ° d ONLN d´∏ <ƒ N * ___ ° d ONLN dØ– <‹ r * Currently, ° d ONLN d∫– r‹˛ )6Mthe dlsDelta field is not being used by Macintosh system software, nor is its ° d ONLN d ‹ <Ë Ë ( Z$meaning defined. There are plans to ° d ONLN d ,‹ Ë˲ )¨=use it in the future, so it’s important that you preserve its ° d ONLN d jË <Ù8 ( Z7current value if you ever use WriteLocation to set the ° d ONLN d °Ë8Ù˛ )¸)value of gmtDelta. See the description of ° d ONLN d ÀÙ < √ ( Z the WriteLocation routine in ° d ONLN d ËÙ √ ˛ )á<“WorldWide Development: Guide to System Software,” available ° d ONLN d
% < ^ (( Zon the ° d ONLN d
, ^ ˛ )"Platest developer CD and from APDA (#M7047/A), for details on getting and setting ° d ONLN d
} <è (4 ZKgmtDelta while leaving dlsDelta intact. In short, the code looks like this: ,
Courier
° d ONLN d
…$ </ _ * VAR ° d ONLN d
—. <9 · *
! myLocation: Location; ° d ONLN d
Û8 <C ‹ *
myGMTDelta: LongInt; ° d ONLN d B <M Î *
# tempSignedByte: SignedByte; ° d ONLN d 8L <W U *
: ° d ONLN d >V <a *
* tempSignedByte := myLocation.dlsDelta; ° d ONLN d i` <k ˙ *
& myLocation.gmtDelta := myGMTDelta; ° d ONLN d êj <u *
* myLocation.dlsDelta := tempSignedByte;
° d ONLN d ªå <õ *& Why 1904 is Macintosh Time base
° d ONLN d €õ <ß b * Written: ° d ONLN d ‰õ àß ¶ )L9/6/91 ◊ X◊
° d ONLN d ) ] *Last reviewed: ° d ONLN d d ) Ç )L8/1/92 ° d ONLN d 5 A M ( ] 6 The global ° d ONLN d ! 5 M A⁄ )5Nvariable Time contains the number of seconds since midnight, Jan. 1, 1904. Why ° d ONLN d p A M ö ( i 6was the year 1904 chosen ? ° d ONLN d ã M Y * * ___ ° d ONLN d è e qê *QThe ability to go back in time is one consideration. You would not want to start ° d ONLN d ‡ eê q⁄ ( çÆthe clock from, ° d ONLN d q }ï ( ô 6Ksay, 1984. You also want to go ahead in time a good amount, of course. So, ° d ONLN d; qï }⁄ ( ô≥the clock start ° d ONLN dK } âë ( • 6Pdate needs to put our current date somewhere in the middle of the clock’s range. ° d ONLN dú ï °ï *QSo what is the clock’s range? Since the clock chip has a four byte counter which ° d ONLN dÌ ïï °⁄ ( Ω≥is incremented ° d ONLN d¸ ° ≠é ( … 6Keach second, they had 4,294,967,295 seconds to work with, or approximately ° d ONLN dG °é ≠⁄ ( …¨136 years. This ° d ONLN dW ≠ π [ ( ’ 6 would make ° d ONLN db ≠ [ π⁄ )CBthe Macintosh clock run out in 1904+136 = 2040. The maximum value, ° d ONLN d• π ≈A ( · 69$FFFFFFFF, corresponds to 6:28:15 a.m., February 6, 2040. ° d ONLN dfl — › *5Given the possible range of years/leap years/nonleap ° d ONLN d — ›⁄ )˚+years (every fourth year, but not if at the ° d ONLN d@ › È å ( 6end of a century, except ° d ONLN dY › å È⁄ )tFat the end of every fourth century, which is a leap year) and the date ° d ONLN d† È ı≈ ( 6\when the clock will run out (2040) - the “leap year code” in the Macintosh only has to deal ° d ONLN d¸ È≈ ı⁄ („with ° d ONLN d ı ( 64the rule “every fourth year is a leap year” because ° d ONLN d5 ı⁄ )Ï,none of the possible Macintosh dates violate ° d ONLN db
? () 6?that rule! Remember, 2000 is evenly divisible by 400, so it IS ° d ONLN d°?
⁄ ()]!a leap year. 1900 is not. If they ° d ONLN d√
¡ (5 6$started at 1900, they would have to ° d ONLN dÁ
° d ONLN dƒ – > * Written: ° d ONLN dƒ d– à )L9/16/91 ° d ONLN d– ‹ ] (¯ 6Last reviewed: ° d ONLN d%– d‹ Ç )L8/1/92 ° d ONLN d,Ë Ù† ( 6LSystem 7 doesn’t recognize some of my 'itl1' resource changes, such as date ° d ONLN dxˆÙ⁄ (æ abbreviation ° d ONLN dÖÙ ÷ ( 6(length, that are recognized by System 6. ° d ONLN dÆ * * ___ ° d ONLN d≤ $ v *The field that you ° d ONLN d≈ v$⁄ )^Brefer to is not doing what you want because System 7 introduced an ° d ONLN d$ 0 (L 63expanded 'itl1' resource, with several new fields, ° d ONLN d;$0⁄ )˚(including arrays that contain the proper ° d ONLN dd0 <A (X 6@abbreviations of all the months and days. If you look in Inside ° d ONLN d§0A<⁄ (X_ Macintosh Volume VI on pages ° d ONLN d¡< H ‡ (d 6+14-87 thru 14-89 you’ll find a description ° d ONLN dÏ< ‡H⁄ )»5of this new resource as well as the rez definition of ° d ONLN d "H Tö (p 6Iit. Note the two new arrays, abbrevDays and abbrevMonths. If you were to ° d ONLN d kHöT⁄ (p∏ modify these ° d ONLN d xT ` õ (| 6 additional fields, you’d see ° d ONLN d ïT õ`⁄ )ÉBthe date in the finder windows change. (In fact, the abbrev length ° d ONLN d ÿ` l= (à 6@field does not seem to be used if these new fields are present.)
° d ONLN d
Ñ ìí *'8'itl0' resource time1Suff…time8Suff field interpretation
. +Z-Developer Support Center ( -Ê October 1992 / X /
° d ONLN d ) < 5Ø ( Q ZNHow are the 'itl0' resource time1Suff, time2Suff, … to be interpreted? On the ° d ONLN d N )Ø 5˛ ( QÕGerman system, ° d ONLN d ] 5 < A é ( ] Zthese bytes seem ° d ONLN d n 5 é A˛ )RKto contain “ Uhr Uhr.” The correct 24-hour time suffix should be a single “ ° d ONLN d ∫ A < M ö ( i ZUhr.” How do we ° d ONLN d A ö M˛ )^Gknow how many bytes of this 8-character entity are significant? Similar ° d ONLN d M < Y» ( u ZWquestion for the mornStr and eveStr: are all 4 characters of each of these significant? ° d ONLN dj Y < e N * ___ ° d ONLN dn q < } *VThe time1Suff…time8Suff fields in the 'itl0' resource of all localized systems divide ° d ONLN dƒ q }˛ ( ôthose ° d ONLN d } < âÀ ( • ZQfields into two sections. The first four bytes (time1Suff through time4Suff) are ° d ONLN d }À Ⲡ( •È used from ° d ONLN d% â < ïU ( ± Z712:00 midnight through one second before noon, and the ° d ONLN d\ âU ï˛ ( ±s"last four bytes (time5Suff through ° d ONLN d ï < °O ( Ω Z7time8Suff) are used from 12:00 noon through one second ° d ONLN d∂ ïO °˛ ( Ωm%before midnight. This is to take into ° d ONLN d‹ ° < ≠Í ( … ZTaccount any system that has hours from 00:00:00 through 23:59:59, but has different ° d ONLN d0 °Í ≠˛ ( …time ° d ONLN d5 ≠ < π p ( ’ Z
J () Z:of four bytes, and any unused bytes are filled with zeros. ° d ONLN dö <% Ê *&By the way, you’ll find that a lot of ° d ONLN d¿ Ê%˛ )™:time suffixes are filled in with something even though the ° d ONLN d˚% <1 i (M Z
flags say ° d ONLN d% i1˛ )-Vthat time suffixes aren’t used. This is just localization garbage, which probably will ° d ONLN d\1 <= ≠ (Y Zbe cleaned up someday. ◊ X◊
(Ï ZInternational Resource Q&As (Ï5 ) of 5 ˇ@ ◊# ˇ ˇˇˇˇ # ◊ ° d WORD S † å ° d WORD R… † Ç
/ Z Å#
0Ià:µú9 " { ˇˇˇˇˇˇˇˇ # † ƒ ° d
ONLN f ˛ † å ° d 1drw2 … -·_ Ä ˇˇˇˇˇˇ è ° ñ x ° d drw2 : ° d drw2 : $ ° d 4drw2 : ° ö ˇ˙ ó@ † ò , Times
. ^ tK^ tK +]BNew Technical Notes † ô ° d drw2 : °„ † ó ° d 1drw2 eÙ Ä ˇˇˇˇˇˇ P ° ñ x ° d drw2 : ° d drw2 : $ ° d 4drw2 : ° ö ˇ˚Ä E¿ † ò
Ä ( {ïDeveloper Support † ô ° d drw2 : °„ † ó ° d `drw2 - Ô ˇˇˇˇˇˇ K Ô - Z f f Z ° d 1drw2 ¿˙È ˇˇˇˇˇˇ K ° ñ x ° d drw2 : ° d drw2 : $ ° d 4drw2 : 0 ° ö ˇÙ Ä † ò
0 ( UÔ † ô ° d drw2 : °„ † ó ° d 1drw2 ÔÊ˙ ˇˇˇˇˇˇ ° ñ x ° d drw2 : ° d drw2 : $ ° d 4drw2 : ° ö ˇ˝Ä † ò
l +& ® † ô ° d drw2 : °„ † ó ° d 1drw2  -¯ y ˇˇˇˇˇˇ ° ñ x ° d drw2 : ° d drw2 : $ ° d 4drw2 : ° ö ˇ˚Ä % † ò
BÄ ( Z \ Macintosh † ô ° d drw2 : °„ † ó † ç ° d drw2 D † É ° d WORD † ç
IR . ° d ONLN d { < é ˝ ( ® ZInternational Canceling
° d ONLN d ç < ú Z *Text ° d ONLN d çQ ú˛ ( ∏oM.TE.InternationalCancel
° d ONLN d 7 ® < ¥ q ( – Z Written by: ° d ONLN d C ® Ñ ¥ ¡ )H John Harvey ° d ONLN d O ®∏ ¥˛ ( –÷
February 1990 ° d ONLN d ] ¿ < Ãö ( Ë ZFThis Technical Note describes potential problems canceling operations ° d ONLN d £ ¿ö Ã˙ ( Ë∏with the Command ° d ONLN d ≥ ¿˙ Ã˛ )`- ° d ONLN d ¥ à < ÿ% ( Ù Z0period key sequence and international keyboards. X
° d ONLN d  ˝ <  *4Where Did That Key Go?
° d ONLN d ¸ <$Ì *RCanceling an operation, from printing to compiling, has always been done with the ° d ONLN dNÌ$˛ (@ key ° d ONLN dR$ <0 (L Z+sequence Command-period. The problem with ° d ONLN d}$ 0˛ )‚/this is that on some international systems, one ° d ONLN d≠0 <<õ (X ZEneeds to hold the Shift key down to produce a period. Many keyboard ° d ONLN dÚ0õ<˛ (Xπmappings, including ° d ONLN d< <H
(d Z,that of the U.S., ignore the Shift key when ° d ONLN d2<
H˛ )Œ.the Command key is down. In other words, on a ° d ONLN daH <TW (p Z8system where a period (.) is a shifted character (e.g., ° d ONLN dôHWT˙ (pu Italian) pressing Command-Shift ° d ONLN d∏H˙T˛ )£- ° d ONLN dπT <` (| Z*KeyThatMakesAPeriod does not generate the ° d ONLN d„T`˛ )ÿ/ASCII code for a period. Instead, the keyboard ° d ONLN d` <li (à Z<mapping software generates the ASCII code for the unshifted ° d ONLN dO`il˛ (àá character. If an application is ° d ONLN dpl <xù (î ZHlooking for Command-period to cancel some time intensive operation, and ° d ONLN d∏lùx˛ (îªan international user ° d ONLN dŒx <Ñ Œ († Z types the shifted key sequence ° d ONLN dÌx ŒÑ˛ )í;that normally produces a period along with the Command key, ° d ONLN d)Ñ <ê¨ (¨ ZRthe application is going to miss that request unless it takes special precautions.
° d ONLN d|® <∑ *' A Bit Confusing (to me at least)
° d ONLN dù√ <œÀ *RThe solution to this potential international disaster is to strip the Command key ° d ONLN dÔ√Àœ˛ (ÎÈ
out of the ° d ONLN d˙œ <€ Æ (˜ Zmodifiers, and then run ° d ONLN dœ Æ€˛ )rBthe key code back through the keyboard mapping software. The trap ,
Courier ° d ONLN dU€ <Á { ( Z _KeyTrans ° d ONLN d^‹ {Ë )?" makes this procedure very easy. ° d ONLN dÄ€ Á[ )° _KeyTrans ° d ONLN dâ‹[Ëy )? takes ° d ONLN dê‹y˲ ) as parameters a pointer to a ° d ONLN d≠Ë <Ù f ( Z'KCHR' ° d ONLN d≥È fı ò )*
resource ° d ONLN dΩÈ òı˛ )2@(see M.TB.KeyMapping), a word which contains the keycode and the ° d ONLN d˛ı <N ( Z;modifier bits, and a word which serves as a state variable. ° d ONLN d: < Ì *#One note on the result returned by ° d ONLN d]
Ì, )± _KeyTrans ° d ONLN df,5 )?. ° d ONLN dh5; ) ° d ONLN di;è )Inside Macintosh ° d ONLN dyè˛ )T, Volume V-195, The ° d ONLN dç <&¡ (B ZRToolbox Event Manager, states, “ASCII 1 is the ASCII value of the first character ° d ONLN dfl¡&˛ (Bfl generated by ° d ONLN dÏ& <2ª (N ZPthe key code parameter.” This statement is followed by an illustration (Figure ° d ONLN d<&ª2˙ (NŸ 7 on page V ° d ONLN dG&˙2˛ )?- ° d ONLN dH2 <> y (Z Z 195) which ° d ONLN dS2 y>˛ )=Gshows ASCII 1 as the low byte of the high word in the long word result. ° d ONLN dú> <Jô (f ZGAlthough this statement and the accompanying illustration are correct, ° d ONLN d„>ôJ˛ (f∑they have mislead a ° d ONLN d˜J <V — (r Z number of people (me for one). ° d ONLN db <n *-It is dangerous to expect the character code ° d ONLN dCb n˛ )Õ3in one particular word of the long word result. In ° d ONLN dwo <{ À (ó Z fact, the architecture of the ° d ONLN dïn Àz
)è _KeyTrans ° d ONLN dûo
{ )?+ trap does not specify which word contains ° d ONLN d…o{˛ )Êthe ° d ONLN dÕ| <à_ (§ Z:character code in which you might be interested. This is ° d ONLN d |_àû (§} because the ° d ONLN d {ûá› )? _KeyTrans ° d ONLN d |›à˛ )? trap’s ° d ONLN d $à <î# (∞ Z0primary purpose is to create a package that can ° d ONLN d Tà#î˛ )Á*be used to build a key-down event, and the ° d ONLN d î <† Î (º Z#Toolbox Event Manager just doesn’t ° d ONLN d ¢î Ά˛ )Ø=care about particular keys. In fact, it is possible to get a ◊ X◊
(Ï ZInternational Canceling (Ï1 ) of 5 ˇ ° ¿Ù%%DSIDICT:_cv
currentdict /bu known {bu}if
userdict /_cv known not{userdict /_cv 30 dict put}if
_cv begin
/bdf{bind def}bind def
currentscreen/cs exch def/ca exch def/cf exch def
/setcmykcolor where{/setcmykcolor get /cvcmyk exch def}{/cvcmyk{1 sub 4 1 roll 3{3 index add neg dup 0 lt{pop 0}if 3 1 roll}repeat setrgbcolor pop}bdf }ifelse
/ss{//cf //ca //cs setscreen}bdf
/stg{ss setgray}bdf
/strgb{ss setrgbcolor}bdf
/stcmyk{ss cvcmyk}bdf
/min1{dup 0 eq{pop 1}if}bdf
end
currentdict /bn known {bn}if
† ør ◊# ˇ ˇˇˇˇ # ◊
IR , Times
. +6-Macintosh Technical Notes / 4 /˘
° d ONLN d * O * result from ,
Courier ° d ONLN d O ) é )7 _KeyTrans ° d ONLN d é * œ )? that contains ° d ONLN d $ œ *⁄ )A5character codes in both words. This is how dead keys ° d ONLN d Z * 6 R ( R 6 are handled. ° d ONLN d g B N *%But how does one handle a particular ° d ONLN d å B N⁄ )≤:character, specifically a period? The strategy adopted in ° d ONLN d « N Z≥ ( v 6[the sample function in this Note is to check both words of the result. If a period exists ° d ONLN d" N≥ Z⁄ ( v— in either ° d ONLN d, Z f∏ ( Ç 6Qword and the Command key is down, it is counted as a Command-period key sequence. ° d ONLN d~ r ~ á *Now that everything is ° d ONLN dï r á ~⁄ )oGstraight about parameters and results, it’s time to look at some sample ° d ONLN d› ~ äO ( ¶ 6Acode. The code fragment which follows ensures that you get that ° d ONLN d ~O ä⁄ ( ¶m period regardless of the state ° d ONLN d= ä ñ { ( ≤ 6of the modifier keys. ° d ONLN dS ¢ Æ _ *
MPW Pascal
° d ONLN d^ ∫ ≈ 1 *CONST ° d ONLN dd ƒ œg *
C kMaskModifier = $FE00; {need to strip command key from Modifiers} ° d ONLN d® Œ Ÿg *
C kMaskVirtualKey = $0000FF00; {get virtual key from event message} ° d ONLN dÏ ÿ „ ö *
kMaskASCII1 = $00FF0000; ° d ONLN d ‚ Ì0 *
8 kMaskASCII2= $000000FF; {get key from KeyTrans return} ° d ONLN d@ Ï ˜ Ü *
kKeyUpMask = $0080; ° d ONLN dW ˆ Å *
kPeriod = ORD('.'); ° d ONLN dm
, *TYPE ° d ONLN dr ö *
EventPtr = ^EventRecord; ° d ONLN dç( 3 *0FUNCTION CmdPeriod(theEvent: EventPtr): Boolean; ° d ONLN dæ2 = ' *
VAR ° d ONLN d¬< G ê *
keyCode : Integer; ° d ONLN d€F Q Y *
virtualKey, ° d ONLN dÈP [ J *
keyInfo, ° d ONLN dÙZ e J *
lowChar, ° d ONLN dˇd o O *
highChar, ° d ONLN d n y @ *
state, ° d ONLN dx É ê *
keyCId : Longint; ° d ONLN d-Ç ç ã *
hKCHR : Handle; ° d ONLN dEñ ° 1 *BEGIN ° d ONLN dK™ µ Ü * CmdPeriod := FALSE; ° d ONLN dbæ …è *K IF ( theEvent^.what = keyDown ) | ( theEvent^.what = autoKey ) THEN BEGIN ° d ONLN dÆ“ ›S *? {see if the command key is down. If it is, get the ASCII } ° d ONLN dÓ‹ Á5 *
9 IF BAND(theEvent^.modifiers,cmdKey) <> 0 THEN BEGIN ° d ONLN d( ˚l *D virtualKey := BAND(theEvent^.message,kMaskVirtualKey) DIV 256; ° d ONLN dm˙ ] *
A {strip the virtual key by ANDing the modifiers with our mask} ° d ONLN dØ 5 *
9 keyCode := BAND(theEvent^.modifiers,kMaskModifier); ° d ONLN dÈ º *
T keyCode := BOR(keyCode,kKeyUpMask); {let KeyTrans think it was a keyup event, ° d ONLN d> # , *
this ° d ONLN dC" -≠ *
Q will keep special dead key processing ° d ONLN dï, 7 , *
from ° d ONLN dõ6 A+ *
7 occurring } ° d ONLN d”@ K ¬ *
" {Finally OR in the virtualKey} ° d ONLN dˆJ U Â *
) keyCode := BOR(keyCode,virtualKey); ° d ONLN d T _ m *
state := 0; ° d ONLN d2h sg *C keyCId := GetScript( GetEnvirons(smKeyScript), smScriptKeys); ° d ONLN dv| á Ô *+ {read the appropriate KCHR resource } ° d ONLN d¢Ü ë Í *
A long virtualKey, keyInfo, lowChar, highChar, state, keyCId; ° d ONLN d"≥ <æ ë *
Handle hKCHR; ° d ONLN d4« <“ ™ * fTimeToQuit = false; ° d ONLN dK€ <Êü *G if (((*theEvent).what == keyDown) || ((*theEvent).what == autoKey)) { ° d ONLN dìÔ <˙Ü *B // see if the command key is down. If it is, find out the ASCII ° d ONLN d÷˘ < *
) // equivalent for the accompanying key. ° d ONLN d
< *( if ((*theEvent).modifiers & cmdKey ) { ° d ONLN d)! <,ü *G virtualKey = ((*theEvent).message & kMaskVirtualKey) >> kShiftWord; ° d ONLN dq+ <6O *
} // end key down event ° d ONLN dƒ « “ Ü *return( fTimeToQuit ); ° d ONLN d€ — ‹ *
}
° d ONLN d› Û À *&What About That Resource
° d ONLN dˆ à *%The astute observer may have noticed ° d ONLN d Ã⁄ )¥8that the code example requires that you read a resource. ° d ONLN dU &ó (B 6UAlthough this certainly isn’t that big of a deal, it is always nice when you can cut ° d ONLN d™ó&⁄ (Bµ down on disk ° d ONLN d∑' 3 } (O 6accesses. In System ° d ONLN dÃ' }3P )e,7.0 a verb is added that can be used to get ° d ONLN d¯&P2§ )” _GetEnvirons ° d ONLN d'§3⁄ )T to return a ° d ONLN d4 @ } (\ 6pointer to the current ° d ONLN d(3 }? ß )e'KCHR' ° d ONLN d.4 ß@p )*+. The verb is defined and used as follows: ° d ONLN dZL X < (t 6Pascal
° d ONLN dË€ Á *(Unfortunately, in system software prior ° d ONLN d€ Ás )ÿto 7.0, you must use ° d ONLN d%⁄sÊ« )É _GetResource ° d ONLN d1€«Á⁄ )T as ° d ONLN d5Ë Ù ≈ ( 6 demonstrated above to obtain ° d ONLN dRË ≈Ù )≠ the current ° d ONLN d^Á Û6 )G'KCHR' ° d ONLN ddË6Ù⁄ )* resource. However, since ° d ONLN dÙ l ( 6 _GetEnvirons ° d ONLN dãı lP )T0 always returns zero when passed a verb it does ° d ONLN dªıP⁄ )‰ not recognize, you can build ° d ONLN dÿ
? () 6>System 7.0 compatibility into your application without having ° d ONLN d?
⁄ ()] to check which system software ° d ONLN d5
N (5 6Bis running. To do this, you could modify the routines as follows: ° d ONLN dx% 1 < *Pascal
° d ONLN d= Hº *TCONST {define our own constant until System 7.0 headers ship. At that point, if you ° d ONLN d‘G R: *
: have not shipped, you can put in the real constant} ° d ONLN dQ \ § *
NewVerb_smKeyCache = 38; ° d ONLN d,[ f ' *
VAR ° d ONLN d0e p r *
KCHRPtr : Ptr; ° d ONLN dCy Ñ! *5 KCHRPtr := Ptr(GetEnvirons(NewVerb_smKeyCache )); ° d ONLN dyÉ é
*
1 hKCHR := NIL; {set to NIL before starting} ° d ONLN d´ó ¢Ö *I IF KCHRPtr = NIL THEN BEGIN {we didn't get the ptr from GetEnvirons} ° d ONLN dı° ¨b *
B keyCId := GetScript(GetEnvirons(smKeyScript), smScriptKeys); ◊ 4◊˘
° d ONLN d ' < 2 ( N Z+ {read the appropriate KCHR resource } ° d ONLN d , 1 < < *
* hKCHR := GetResource('KCHR',keyCId); ° d ONLN d W ; < F ¥ *
KCHRPtr := hKCHR^; ° d ONLN d p E < P d *
END; ° d ONLN d y Y < d ‹ * IF KCHRPtr <> NIL THEN BEGIN ° d ONLN d ö c < nà *
P { we don't need to lock the resource since KeyTrans will not move memory } ° d ONLN d Î m < x1 *
1 keyInfo := KeyTrans(KCHRPtr,keyCode,state); ° d ONLN d w < Ç æ *
IF hKCHR <> NIL THEN ° d ONLN d8 Å < å ◊ *
ReleaseResource(hKCHR); ° d ONLN dX ã < ñ _ *
END
° d ONLN d` ° < ≠ E *C
° d ONLN db π < ƒ" *./* again we define our own constant for now */ ° d ONLN dë √ < Œ Õ *
#define NewVerb_smKeyCache 38 ° d ONLN dØ ◊ < ‚ x * Ptr KCHRPtr; ° d ONLN dº Î < ˆO *7 hKCHR = nil; /* set this to nil before starting */ ° d ONLN dÙ ı < @ *
4 KCHRPtr = (Ptr)GetEnvirons(NewVerb_smKeyCache ); ° d ONLN d) < • * IF ( !KCHRPtr ) { ° d ONLN d? < Ü *
B keyCId = GetScript( GetEnvirons(smKeyScript), smScriptKeys); ° d ONLN dÇ' <2 *+ hKCHR = GetResource('KCHR',keyCId); ° d ONLN dÆ1 << Ø *
KCHRPtr = *hKCHR; ° d ONLN dΔ; <F Z *
}; ° d ONLN dÕO <Z ñ * IF (KCHRPtr) { ° d ONLN d‡Y <d6 *
2 keyInfo := KeyTrans(KCHRPtr ,keyCode,state); ° d ONLN dc <n å *
if (hKCHR) ° d ONLN d$m <x ◊ *
ReleaseResource(hKCHR); ° d ONLN dDw <Ç U *
}
° d ONLN dJ• <± ¶ */Further Reference: – X– ° d ONLN d]≤ Næ R +
• ° d ONLN d_≤ `æ ± )Inside Macintosh ° d ONLN do≤ ±æL )Q , Volume V, The Script Manager ° d ONLN déæ N R (Ê l• ° d ONLN dêæ ` ± )Inside Macintosh ° d ONLN d†æ ± v )Q%, Volume V, The Toolbox Event Manager ° d ONLN dΔ N÷ R (Ú l• ° d ONLN d» `÷ ø )M.TB.KeyMapping ◊ X◊
ONLN f ˛ † å ° d 1drw2 … -·_ Ä ˇˇˇˇˇˇ è ° ñ x ° d drw2 : ° d drw2 : $ ° d 4drw2 : ° ö ˇ˙ ó@ † ò , Times
. R… R… +]BNew Technical Notes † ô ° d drw2 : °„ † ó ° d 1drw2 eÙ Ä ˇˇˇˇˇˇ P ° ñ x ° d drw2 : ° d drw2 : $ ° d 4drw2 : ° ö ˇ˚Ä E¿ † ò
( {ïDeveloper Support † ô ° d drw2 : °„ † ó ° d `drw2 - Ô ˇˇˇˇˇˇ K Ô - Z f f Z ° d 1drw2 ¿˙È ˇˇˇˇˇˇ K ° ñ x ° d drw2 : ° d drw2 : $ ° d 4drw2 : 0 ° ö ˇÙ Ä † ò
0 ( UÔ † ô ° d drw2 : °„ † ó ° d 1drw2 ÔÊ˙ ˇˇˇˇˇˇ ° ñ x ° d drw2 : ° d drw2 : $ ° d 4drw2 : ° ö ˇ˝Ä † ò
+& ® † ô ° d drw2 : °„ † ó ° d 1drw2  -¯ y ˇˇˇˇˇˇ ° ñ x ° d drw2 : ° d drw2 : $ ° d 4drw2 : ° ö ˇ˚Ä % † ò
( Z \ Macintosh † ô ° d drw2 : °„ † ó † ç ° d drw2 D † É
IR . ° d ONLN d z < çÀ ( ß Z0Changes in International Utilities and Resources
° d ONLN d 1 å < õ Z *Text ° d ONLN d 7 åå õ˛ ( ∑™M.TE.IUChanges
° d ONLN d F ß < ≥ t ( œ Z Revised by: ° d ONLN d S ß≈ ≥˛ ( œ„
in primary ° d ONLN d◊ <)å (E ZFordering but different in secondary ordering (e.g., “ä” and “a”). The ° d ONLN d å)˛ (E™routine can also handle ° d ONLN d5) <5
(Q Z.cases where one character sorts as if it were ° d ONLN dc)
5˛ )—1two, or two characters would sort as if they were ° d ONLN dï5 <A ’ (] Z!one, or even character reversals. ° d ONLN d∑M <Yl *BPrior to System 4.1, the international sorting routine was stored ° d ONLN d˘MlY˛ (uä starting with the localRtn field ° d ONLN dY <e I (Å Zof ° d ONLN d Y Ie˛ )
XINTL 1. As of System 4.1, this routine is now stored in itl2. An INTL 2 resource is also ° d ONLN dve <q ê (ç Zincluded with the ° d ONLN dàe êq˛ )TOinternational resources, just for consistency (the System never uses it). It is ° d ONLN dÿq <} ¨ (ô Zexactly the same as itl2. ° d ONLN dÚ} <â Î * !Writing your own sorting routine ° d ONLN d } ÎⲠ)Ø4can be dangerous if it is not done correctly. Before ° d ONLN d Hâ <ï (± ZVattempting to do this, we would highly recommend you check with Apple to determine if ° d ONLN d ûâï˛ (±we ° d ONLN d °ï <°» (Ω ZUare already doing one for the language of interest. We plan to do many international ° d ONLN d ˆï»°˛ (ΩÊ versions of ° d ONLN d
° <≠ (… Z,System file 4.1, and most developers’ needs ° d ONLN d
.°≠˛ )’0will be met by these. A new policy at Apple will ◊ X◊
(Ï Z0Changes in International Utilities and Resources (Ï1 ) of 2 ˇ ° ¿Ù%%DSIDICT:_cv
currentdict /bu known {bu}if
userdict /_cv known not{userdict /_cv 30 dict put}if
_cv begin
/bdf{bind def}bind def
currentscreen/cs exch def/ca exch def/cf exch def
/setcmykcolor where{/setcmykcolor get /cvcmyk exch def}{/cvcmyk{1 sub 4 1 roll 3{3 index add neg dup 0 lt{pop 0}if 3 1 roll}repeat setrgbcolor pop}bdf }ifelse
/ss{//cf //ca //cs setscreen}bdf
/stg{ss setgray}bdf
/strgb{ss setrgbcolor}bdf
/stcmyk{ss cvcmyk}bdf
/min1{dup 0 eq{pop 1}if}bdf
end
currentdict /bn known {bn}if
† øê ◊# ˇ ˇˇˇˇ # ◊
IR , Times
. +6-Macintosh Technical Notes / 4 /˘
° d ONLN d ) L * now make ° d ONLN d L )⁄ )4Sit possible to license foreign versions of the System file from Software Licensing. ° d ONLN d ] ) 5è ( Q 6MContact Software Licensing at (408) 973-4667 for more information about this. ° d ONLN d ´ M Y< *$0Error in APDA draft of Inside Macintosh Volume V ° d ONLN d › e q C * There is ° d ONLN d Ê e C qΩ )+Man error in the APDA draft of the International Utilities Package chapter of ° d ONLN d3 eΩ q⁄ ( ç€Inside ° d ONLN d: q } | ( ô 6Macintosh Volume V ° d ONLN dL q | }ú )dB. It says that there is a flag in the Script Manager globals that ° d ONLN dé qú }⁄ ( ô∫
overrides the ° d ONLN dú } âµ ( • 6Ucurrent font and always uses the INTL 0 and INTL 1 resources. This is not true. INTL ° d ONLN dÒ }µ â⁄ ( •”0 and 1 ° d ONLN d˘ â ïà ( ± 6]have been replaced by itl0 and itl1, and are not used except by applications that explicitly ° d ONLN dV âà ï⁄ ( ±Íget ° d ONLN dZ ï ° 2 ( Ω 6them ° d ONLN d_ ï 2 °⁄ )Xby doing a GetResource. There is a relevant Script Manager flag called IntlForce that is ° d ONLN d∏ ° ≠Æ ( … 6Vcorrectly but incompletely explained in the Script Manager chapter. When IntlForce is ° d ONLN d °Æ ≠⁄ ( …Ã
false, the ° d ONLN d ≠ πs ( ’ 6Lresources used by the International Utilities are determined by the current ° d ONLN de ≠s π⁄ ( ’ëscript. The script that ° d ONLN d} π ≈— ( · 6`is in use is determined by which font is in use for the port in use. For example, if you switch ° d ONLN d› π— ≈⁄ ( ·Ôto ° d ONLN d‡ ≈ —» ( Ì 6\the Kyoto font, then you will be using the Japanese Script Interface System (KanjiTalk). If ° d ONLN d< ≈» —⁄ ( ÌÊyou ° d ONLN d@ — › Å ( ˘ 6do this with IntlForce ° d ONLN dW — Å ›⁄ )iJset to false, then you will use the resources that are associated with the ° d ONLN d¢ › È ∑ ( 6!Japanese Script Interface System. ° d ONLN dƒ ı ™ *VWhen IntlForce is true, the International Utilities always use the resources that are ° d ONLN d ı™⁄ ( »
associated ° d ONLN d%
§ () 6 with the system script; this is ° d ONLN dE §
⁄ )åAusually Roman. IntlForce is true by default. Actually, the Script ° d ONLN dá
u (5 6MManager initialization routine reads the itlc resource to determine what the ° d ONLN d‘
u⁄ (5ìdefault is, and Apple ° d ONLN dÍ %T (A 6Bplans to release the various international System files with this ° d ONLN d,T%⁄ (Ar field set to true in the itlc ° d ONLN dJ% 1} (M 6Jresource. Applications that want to change the value of IntlForce can use ° d ONLN dî%}1⁄ (Mõthe Script Manager ° d ONLN dß1 = h (Y 6call SetEnvirons ° d ONLN d∏1 h=⁄ )PNwith the smIntlForce verb. There is a Script Manager call, IntlScript, to find ° d ONLN d= I | (e 6out the current value. ° d ONLN d a m ◊ *$!Bug in System 4.1 version of itl1 ° d ONLN d@y Ö ç *There is a bug in the itl1 ° d ONLN d[y çÖ⁄ )uDresource in System 4.1. The itl1 resource contains arrays of day and ° d ONLN d†Ö ë8 (≠ 6;month names, as did the INTL 1 resource. Their formats are: ,
Courier
° d ONLN d‹ù ® ≥ * days ARRAY [1..7] of STRING[15] ° d ONLN d¸ß ≤ Ω *
!months ARRAY[1..12] OF STRING[15]
° d ONLN d Ω …B *8Every day and month is supposed to be coded as a Pascal ° d ONLN dVΩB…⁄ (Â`string with a maximum of 15 ° d ONLN dr… ’ Ω (Ò 6%characters, and the actual length in ° d ONLN dó… Ω’⁄ )•;the first byte of the string. In System 4.0 and System 4.1, ° d ONLN d”’ ·ö (˝ 6Tthe contents of each string is always a Pascal string of length 15, with the unused ° d ONLN d '’ö·⁄ (˝∏characters set ° d ONLN d 6· Ì ‚ ( 6-to nulls. In other words, the length byte is ° d ONLN d c· ‚Ì⁄ ) 5set to hex 0F. This will be fixed in a future release ° d ONLN d ôÌ ˘ Ç ( 6of the System file. If ° d ONLN d ∞Ì Ç˘⁄ )jEit is currently causing your application problems, you can change the ° d ONLN d ˆ˘ c (! 6Blengths with ResEdit, or change them at run time, or use your own ° d ONLN d
8˘c⁄ (!Åitl1 resource and release ° d ONLN d
R ∑ (- 6Syour application with an installer script. The recommended approach is to wait for ° d ONLN d
•∑⁄ (-’a fixed ° d ONLN d
≠ Œ (9 6&version of the System file from Apple. ° d ONLN d
‘A M Ç *0Further Reference: l 4l˘ ° d ONLN d
ÁN *Z . +
• ° d ONLN d
ÈN <Z ¥ )The International Utilities ° d ONLN d Z *f . (Ç H• ° d ONLN d Z <f ô )The Script Manager ◊ 4◊˘
(Ï 62 ) of 2 )¸0Changes in International Utilities and Resources ˇ≤ ◊# ˇ ˇˇˇˇ # ◊ † Ç
/ Z Å#
0Ià:µú9 " { ˇˇˇˇˇˇˇˇ # † ƒ ° d
ONLN f ˛ † å ° d 1drw2 … -·_ Ä ˇˇˇˇˇˇ è ° ñ x ° d drw2 : ° d drw2 : $ ° d 4drw2 : ° ö ˇ˙ ó@ † ò , Times
. R… R… +]BNew Technical Notes † ô ° d drw2 : °„ † ó ° d 1drw2 eÙ Ä ˇˇˇˇˇˇ P ° ñ x ° d drw2 : ° d drw2 : $ ° d 4drw2 : ° ö ˇ˚Ä E¿ † ò
( {ïDeveloper Support † ô ° d drw2 : °„ † ó ° d `drw2 - Ô ˇˇˇˇˇˇ K Ô - Z f f Z ° d 1drw2 ¿˙È ˇˇˇˇˇˇ K ° ñ x ° d drw2 : ° d drw2 : $ ° d 4drw2 : 0 ° ö ˇÙ Ä † ò
0 ( UÔ † ô ° d drw2 : °„ † ó ° d 1drw2 ÔÊ˙ ˇˇˇˇˇˇ ° ñ x ° d drw2 : ° d drw2 : $ ° d 4drw2 : ° ö ˇ˝Ä † ò
+& ® † ô ° d drw2 : °„ † ó ° d 1drw2  -¯ y ˇˇˇˇˇˇ ° ñ x ° d drw2 : ° d drw2 : $ ° d 4drw2 : ° ö ˇ˚Ä % † ò
( Z \ Macintosh † ô ° d drw2 : °„ † ó † ç ° d drw2 D † É
IR . ° d ONLN d n < Å ( õ ZKeyboard Resource Q&As
° d ONLN d Ä < è Z *Text ° d ONLN d Äd è˛ ( ´ÇM.TX.KeybdRes.Q&As
° d ONLN d 0 õ < ß t ( √ Z Revised by: ° d ONLN d < õ Ñ ß ˇ )HDeveloper Support Center ° d ONLN d U õæ ߲ ( √‹ October 1992 ° d ONLN d b ß < ≥ q ( œ Z Written by: ° d ONLN d n ß Ñ ≥ ˇ )HDeveloper Support Center ° d ONLN d á ßæ ≥˛ ( œ‹ October 1990 ° d ONLN d î ø < À ⁄ ( Á Z This Technical Note contains a ° d ONLN d ≥ ø ⁄ À˛ )û9collection of Q&As relating to a specific topic—questions ° d ONLN d Ì À < ◊† ( Û ZGyou’ve sent the Developer Support Center (DSC) along with answers from ° d ONLN d4 À† ◊˛ ( Ûæthe DSC engineers. ° d ONLN dG ◊ < „ u ( ˇ Z
° d ONLN d Ä <èå *4/ResEdit and Macintosh Portable 'KCAP' resources
° d ONLN d9è <õ b * Written: ° d ONLN dBè àõ ¨ )L6/17/91 ° d ONLN dJõ <ß Å (√ ZLast reviewed: ° d ONLN dYõ àß ¨ )L1/27/92 ° d ONLN da≥ <øe (€ Z=I am trying to use the 'KCAP' resource to draw the Macintosh ° d ONLN dû≥eø˛ (€É Portable keyboard layout in our ° d ONLN dæø <À≥ (Á ZMapplication. I used the ResEdit to check 'KCAP' in both System 7 and the Key ° d ONLN d ø≥À˛ (Á—Layout file, but ° d ONLN d À <◊ ı (Û Z(the Portable keyboard type is not there. ° d ONLN dE◊ <„ N * ___ ° d ONLN dIÔ <˚ *+The resource numbers 6 and 7 of 'KCAP' are ° d ONLN dtÔ˚˛ )€-contained in the ROM of the Portable and some ° d ONLN d¢˚ <∫ (# ZMother Macintosh models. Being located in ROM, the resources are not directly ° d ONLN dÔ˚∫˛ (#ÿ
viewable with ° d ONLN d˝ <
(/ Z(ResEdit. They do, however, exist in the ° d ONLN d%
˛ )Œ,resource chain, so a RGetResource for 'KCAP' ° d ONLN dR < √ (; ZNnumber 6 should load and return a pointer to this resource. ROM resources and ° d ONLN d†√ ˛ (;· the resource ° d ONLN d≠ <+˘ (G ZZchain are discussed in the Resource Manager chapters of Inside Macintosh Volumes IV and V.
° d ONLN dC <Rú *'0Using Macintosh KCAP resource to draw a keyboard
° d ONLN d9R <^ b * Written: ° d ONLN dBR à^ ¨ )L1/10/92 ° d ONLN dJ^ <j Å (Ü ZLast reviewed: ° d ONLN dY^ àj ¶ )L4/7/92 ° d ONLN d`v <ÇL (û Z5How can I use the KCAP resource to draw the keyboard? ° d ONLN dñÇ <é N * ___ ◊ X◊
*BKeyboard Resource Q&As (Ï1 ) of 3 ˇ ° ¿Ù%%DSIDICT:_cv
currentdict /bu known {bu}if
userdict /_cv known not{userdict /_cv 30 dict put}if
_cv begin
/bdf{bind def}bind def
currentscreen/cs exch def/ca exch def/cf exch def
/setcmykcolor where{/setcmykcolor get /cvcmyk exch def}{/cvcmyk{1 sub 4 1 roll 3{3 index add neg dup 0 lt{pop 0}if 3 1 roll}repeat setrgbcolor pop}bdf }ifelse
/ss{//cf //ca //cs setscreen}bdf
/stg{ss setgray}bdf
/strgb{ss setrgbcolor}bdf
/stcmyk{ss cvcmyk}bdf
/min1{dup 0 eq{pop 1}if}bdf
end
currentdict /bn known {bn}if
† ø: ◊# ˇ ˇˇˇˇ # ◊
IR , Times
. +6-Macintosh Technical Notes / 4 /˘
° d ONLN d )Œ *YKCAP resources describe the key layout of Macintosh keyboards. They are intended for use ° d ONLN d Y Œ )⁄ ( EÏby ° d ONLN d \ ) 5 Ä ( Q 6the Key Caps desk ° d ONLN d n ) Ä 5⁄ )h@accessory, but applications can also take advantage of KCAPs for ° d ONLN d Ø 5 A Õ ( ] 6$information about key arrangements. ° d ONLN d ” 5 Õ A⁄ )µ0The program kcapApp demonstrates use of the KCAP ° d ONLN d A M ( i 65resource and is available in the Snippets collection. ° d ONLN d: Y e ⁄ *(This is the format of the KCAP resource: ° d ONLN dc q } · *+ rect, boundary for the keyboard (8 bytes) ° d ONLN dè } â * : rect, appropriate for an editable line of text (8 bytes) ° d ONLN d â ï * 3 integer, number of key shapes to follow (2 bytes) ° d ONLN d ° ≠ y * for each key shape: ° d ONLN d ≠ πI * C integer, number of points defining this key shape - 1 (2 bytes) ° d ONLN d[ π ≈ h * for each point: ° d ONLN do ≈ — Ë * 0 point, opposite corner of a rect (2 bytes) ° d ONLN d† › È Í *. number of keys of this shape - 1 (2 bytes) ° d ONLN dœ È ı a * for each key: ° d ONLN d· ı ± * " byte, modifier mask (1 byte) ° d ONLN d
" * 9 byte, OR/AND setting for modifier mask (1 bit) plus ° d ONLN d>
9 E£ (a 6Qa 7-bit virtual keycode, plus a mask for the modifiers to be passed to KeyTrans. ° d ONLN d [9£E⁄ (a¡ If the most ° d ONLN d gE Qs (m 6Ksignificant bit of the keycode byte is set, AND the desired modifiers with ° d ONLN d ≤EsQ⁄ (mëthe modifier mask. If ° d ONLN d »Q ] ˙ (y 61the bit is clear, OR the modifiers with the mask. ° d ONLN d ˙i uO *CThe high bit of the virtual keycode byte indicates to KeyTrans the ° d ONLN d
=iOu⁄ (ëm type of the keystroke; before ° d ONLN d
[u Å ∫ (ù 6$calling KeyTrans, clear the bit for ° d ONLN d
u ∫Å⁄ )¢<a keydown, or set it for a keyup. The bit should be clear if ° d ONLN d
. +Z-Developer Support Center ( -Ê October 1992 / X /
° d ONLN d < )æ ( E ZMThe global KbdType ($21E), a byte, contains the KCAP resource number for the ° d ONLN d M æ )˛ ( E‹
last keyboard ° d ONLN d [ ) < 5m ( Q Z:used. Under System 6, KCAP resources are kept in the file ° d ONLN d ï )m 5˛ ( Qã“Key Layout” in the System ° d ONLN d ∞ 5 < A˘ ( ] ZVfolder. Starting with System 7, KCAP resources are in the System file. Alternatively, ° d ONLN d 5˘ A˛ ( ]a ° d ONLN d A < MÖ ( i Z?machine’s KCAP may be stored in ROM, where it’s available with ° d ONLN dG AÖ M˛ ( i£the GetResource call but ° d ONLN d` M < Y “ ( u Z cannot be viewed with ResEdit. ° d ONLN d e < q ˙ *%For more information on KeyTrans and ° d ONLN d§ e ˙ q˛ )æ0KCHRs, see Chapter 10 of Inside Macintosh Volume ° d ONLN d’ q < } Ë ( ô Z#V, pages 14-23 and 14-96 of Inside ° d ONLN d¯ q Ë }˛ )¨5Macintosh Volume VI, and the Macintosh Technical Note ° d ONLN d. } < âò ( • ZC“Key Mapping.” KCAP resources are discussed on pages 14-95, 14-100 ° d ONLN dq }ò Ⲡ( •∂and 14-101 of Inside ° d ONLN dÜ â < ï ® ( ± ZMacintosh Volume VI.
° d ONLN dõ ≠ < ºy *'-Macintosh Option key: Techniques for ignoring
° d ONLN d… º < » b * Written: ° d ONLN d“ º à » ≤ )L10/16/91 ° d ONLN d€ » < ‘ Å ( ZLast reviewed: ° d ONLN dÍ » à ‘ ¨ )L2/28/92 ° d ONLN dÚ ‡ < Ï à ( ZI would like to ° d ONLN d ‡ à Ï˛ )LIuse the Macintosh Option key as the Control key for keyboards that lack a ° d ONLN dL Ï < ¯ d ( ZControl ° d ONLN dT Ï d ¯˛ )(Nkey, such as for Macintosh Plus keyboards. How can I find the ASCII value that ° d ONLN d£ ¯ <À ( ZSwould have been returned if the Option key weren’t pressed, in a way that would be ° d ONLN dˆ ¯À˛ ( È
compatible ° d ONLN d < • (, Zwith other keyboards? ° d ONLN d < N * ___ ° d ONLN d( <4 *+There are a couple of clean ways to ignore ° d ONLN dF(4˛ ) 2the Option key. One is to “reprocess” the keyboard ° d ONLN dy4 <@ (\ Z/event. The fourth byte of the event message is ° d ONLN d®4@˛ )‹1the ASCII code, but the third byte is the virtual ° d ONLN d⁄@ <L œ (h Z key code. The system calls the ° d ONLN d˘@ œL˛ )ì<trap KeyTrans to map the virtual key code to ASCII according ° d ONLN d6L <X (t Z+to a 'KCHR' resource. You can do the same, ° d ONLN daLX˛ )Ÿ1and since the high byte of the modifiers are part ° d ONLN dìX <d ˜ (Ä Z(of the input to KeyTrans, you can strip ° d ONLN dªX ˜d˛ )ª6out the Option key, call KeyTrans on the third byte of ° d ONLN dÚd <p (å Z+the event message, and get back the “true” ° d ONLN d dp˛ ) -ASCII keypress. KeyTrans and 'KCHR' resources ° d ONLN dKp <|U (ò Z8are documented in Chapter 10 of Inside Macintosh Volume ° d ONLN dÉpU|˛ (òs!V, Chapter 14 of Inside Macintosh ° d ONLN d•| <àÇ (§ Z?Volume VI (pages 14-23 and 14-96), and the Macintosh Technical ° d ONLN d‰|Çà˛ (§†Note “Key Mapping.” In ° d ONLN d˚à <î (∞ Z.Pascal, these steps would look something like: ,
Courier
° d ONLN d*† <´ï *E keycode := BAND(event.message, keyCodeMask); { get virtual code } ° d ONLN dp™ <µ@ *
4 keycode := BSR(keycode, 8); { move to low byte } ° d ONLN d•¥ <ø Ê *
" { now combine with modifiers } ° d ONLN d»æ <…^ *
° d ONLN d{Ë <Ù é *The resource ID ° d ONLN dãË éÙ˛ )RGof the current KCHR is available as GetScript(GetEnvirons(smKeyScript), ° d ONLN d”Ù < a ( Z9smScriptKeys). Alternatively, a pointer to the KCHR data ° d ONLN d Ùa ˛ ( is available under System 7 as ° d ONLN d + < fi (( ZRGetEnvirons(smKCHRCache), as discussed in the Tech Note “International Canceling.” ° d ONLN d ~ <$ T *This ° d ONLN d É T$˛ )Tmethod may work for you, but there is a possible problem: dead keys. Since dead keys ° d ONLN d ÿ$ <0” (L ZYare processed before your application gets the event, your application will not see (for ° d ONLN d
1$”0˛ (LÒexample) ° d ONLN d
:0 <<› (X ZWthe first Option-e typed. However, the dead keys are specified in the 'KCHR' resource, ° d ONLN d
ë0›<˛ (X˚so you ° d ONLN d
ò< <Hg (d Z>can create a KCHR (ResEdit 2.1.1 includes a template) to omit ° d ONLN d
÷<gH˛ (dÖ dead keys (and, if you choose, ° d ONLN d
ıH <T ß (p Zoption characters) and ° d ONLN d H ßT˛ )kIinclude it with your application. Call SetScript to get the system to use ° d ONLN d VT <`Ω (| ZIyour 'KCHR' (see the Tech Note “Key Mapping,” IM V-313, and IM VI 14-40). ° d ONLN d †l <x‚ *RAnother problem is that System 7 ignores a 'KCHR' in the application’s resources, ° d ONLN d Úl‚x˛ (î so an ° d ONLN d ¯x <ÑŸ († ZSapplication’s 'KCHR' has to be installed in the system. You can install the 'KCHR' ° d ONLN d KxŸÑ˛ (†˜with an ° d ONLN d SÑ <êH (¨ Z8installer program, or provide a keyboard file users can ° d ONLN d ãÑHê˛ (¨f%drag to the System file. (To create a ° d ONLN d ±ê <ú$ (∏ Z0keyboard file, use ResEdit to put the 'KCHR' in ° d ONLN d ·ê$ú˛ )Ë.the System file, and then drag it out with the ° d ONLN d
ONLN f ˛ † å ° d 1drw2 … -·_ Ä ˇˇˇˇˇˇ è ° ñ x ° d drw2 : ° d drw2 : $ ° d 4drw2 : ° ö ˇ˙ ó@ † ò , Times
. R… R… +]BNew Technical Notes † ô ° d drw2 : °„ † ó ° d 1drw2 eÙ Ä ˇˇˇˇˇˇ P ° ñ x ° d drw2 : ° d drw2 : $ ° d 4drw2 : ° ö ˇ˚Ä E¿ † ò
( {ïDeveloper Support † ô ° d drw2 : °„ † ó ° d `drw2 - Ô ˇˇˇˇˇˇ K Ô - Z f f Z ° d 1drw2 ¿˙È ˇˇˇˇˇˇ K ° ñ x ° d drw2 : ° d drw2 : $ ° d 4drw2 : 0 ° ö ˇÙ Ä † ò
0 ( UÔ † ô ° d drw2 : °„ † ó ° d 1drw2 ÔÊ˙ ˇˇˇˇˇˇ ° ñ x ° d drw2 : ° d drw2 : $ ° d 4drw2 : ° ö ˇ˝Ä † ò
+& ® † ô ° d drw2 : °„ † ó ° d 1drw2  -¯ y ˇˇˇˇˇˇ ° ñ x ° d drw2 : ° d drw2 : $ ° d 4drw2 : ° ö ˇ˚Ä % † ò
( Z \ Macintosh † ô ° d drw2 : °„ † ó † ç ° d drw2 D † É
IR . ° d ONLN d z < çp ( ß Z#Script Manager’s Pixel2Char Routine
° d ONLN d $ å < õ Z *Text ° d ONLN d * åâ õ˛ ( ∑ßM.TE.Pixel2Char
° d ONLN d : ß < ≥ t ( œ Z Revised by: ° d ONLN d F ß Ñ ≥( )H Mark B. Johnson & Dave McGary ° d ONLN d d ß¡ ≥˛ ( œfl August 1989 ° d ONLN d p ≥ < ø q ( € Z Written by: ° d ONLN d | ≥ Ñ ø ª )H Sue Bartalo ° d ONLN d à ≥Õ ø˛ ( €Î June 1989 ° d ONLN d í à < ÿ fl ( Ù Z"This Technical Note discusses the ,
Courier ° d ONLN d ¥ À fl ◊% )£
Pixel2Char ° d ONLN d æ Ã% ÿ )F( routine provided by the Script Manager. ° d ONLN d Á ÿ < ‰ œ ( ZChanges since June 1989: ° d ONLN d ˇ ÿ œ ‰å )ì) Clarified information, corrected minor ° d ONLN d( ÿå ‰˛ )Ωerrors, and replaced the ° d ONLN dA ‰ < r ( Z
illustration. X ° d ONLN dO
< R *&The ° d ONLN dS R ä )leftSide ° d ONLN d[
ä √ )8
flag in the ° d ONLN dh √ )9
Pixel2Char ° d ONLN dr
I )F
routine was ° d ONLN d
I˛ )@$inappropriately named, and it should ° d ONLN d§ <# ù (? Znow be called the ° d ONLN d∂ ù" Í )a leadingEdge ° d ONLN d¡ Í#˛ )M4 flag. The reason for this change is that the value ° d ONLN dˆ# </ Ç (L Z
° d ONLN d~ê <õ‡ *TFUNCTION Pixel2Char(textBuf: Ptr;textLen: INTEGER;slop: INTEGER;pixelWidth: INTEGER; ° d ONLN d”ö <•; *
3 VAR leftSide: BOOLEAN): INTEGER; ° d ONLN dÆ <π¬ *Npascal short Pixel2Char(Ptr textBuf,short textLen,short slop,short pixelWidth, ° d ONLN dV∏ <√ *
) Boolean *leftSide)
° d ONLN dÄŒ <⁄ ì *New Definition
° d ONLN dèÊ <Ò‡ *TFUNCTION Pixel2Char(textBuf: Ptr;textLen: INTEGER;slop: INTEGER;pixelWidth: INTEGER; ° d ONLN d‰ <˚J *
6 VAR leadingEdge: BOOLEAN): INTEGER; ° d ONLN d <¬ *Npascal short Pixel2Char(Ptr textBuf,short textLen,short slop,short pixelWidth, ° d ONLN dj < *
, Boolean *leadingEdge)
° d ONLN dó% <1 ã *The value of the ° d ONLN d®$ ã0 ÿ )O leadingEdge ° d ONLN d≥% ÿ1 ˚ )M flag is ° d ONLN dº$ ˚0 )#True ° d ONLN d¿%1$ ) if ° d ONLN dƒ%$1˛ )
*a mouse-down occurs on the leading edge of ° d ONLN dÔ1 <=Ë (Y Z_the character in its direction (e.g., the left side for a left-to-right script (Roman) and the ° d ONLN dN1Ë=˛ (Yright ° d ONLN dT= <I— (e ZZside for a right-to-left one (Arabic or Hebrew)). Figure 1 illustrates these differences. ° d ONLN dØU <a_ *8This Note describes the way script systems should work; ° d ONLN dÁU_a˛ (}} however, in some systems, the ° d ONLN db <n p (ä Z
pixelWidth ° d ONLN dQbÔn˛ )F is ° d ONLN dUn <z ‹ (ñ Z#outside the boundaries of the text. ° d ONLN dyÜ <íÿ *UYou define the start of a right-to-left line to be on the right and the end to be on ° d ONLN dŒÜÿí˛ (ƈ the left; ° d ONLN dÿí <ûä (∫ ZMtherefore, it follows that the start of a left-to-right line is on the left, ° d ONLN d%íäû˛ (∫®while the end is on the ° d ONLN d=ü <´ ¥ (« Zright. The values at the ° d ONLN dWü ¥´ Õ )xstart ° d ONLN d\ü Õ´ fl ) of ° d ONLN d`ü fl´4 )a line should be ° d ONLN dqû4™W )UFalse ° d ONLN dvüW´o )# for ° d ONLN d{ûo™º ) leadingEdge ° d ONLN dÜüº´˛ )M
userdict /_cv known not{userdict /_cv 30 dict put}if
_cv begin
/bdf{bind def}bind def
currentscreen/cs exch def/ca exch def/cf exch def
/setcmykcolor where{/setcmykcolor get /cvcmyk exch def}{/cvcmyk{1 sub 4 1 roll 3{3 index add neg dup 0 lt{pop 0}if 3 1 roll}repeat setrgbcolor pop}bdf }ifelse
/ss{//cf //ca //cs setscreen}bdf
/stg{ss setgray}bdf
/strgb{ss setrgbcolor}bdf
/stcmyk{ss cvcmyk}bdf
/min1{dup 0 eq{pop 1}if}bdf
end
currentdict /bn known {bn}if
† ø=$ ◊# ˇ ˇˇˇˇ # ◊
IR , Times
. +6-Macintosh Technical Notes / 4 /˘
° d ONLN d * ´ *!character offset. The values at ° d ONLN d ! ´ * Ω )ìthe ° d ONLN d % Ω * — )end ° d ONLN d ( — * Á ) are ,
Courier ° d ONLN d - Á ) )True ° d ONLN d 1 * ) for ° d ONLN d 6 )f ) leadingEdge ° d ONLN d A f *⁄ )M and the character offset ° d ONLN d [ * 6 Ê ( R 6+is the total byte count of that line. You ° d ONLN d Ü * Ê 6⁄ )Œ/should check for these out-of-bounds conditions ° d ONLN d ∂ 6 B É ( ^ 6explicitly and perform ° d ONLN d Õ 6 É B⁄ )kHthe appropriate actions. This change will appear in the next version of ° d ONLN d B N Ω ( j 6!the Script Manager documentation. † Ç † å † å ° ñ ° ö ˇ¸ ë
z < ãa
3·3· ° d ONLN dˇˇ + "Character and Line Direction Equal † ó ° ÿ ˇˇÄ ° ÷ ˇˇÄ † ◊ ° ¥
ONLN f ˛ † å ° d 1drw2 … -·_ Ä ˇˇˇˇˇˇ è ° ñ x ° d drw2 : ° d drw2 : $ ° d 4drw2 : ° ö ˇ˙ ó@ † ò , Times
. R… R… +]BNew Technical Notes † ô ° d drw2 : °„ † ó ° d 1drw2 eÙ Ä ˇˇˇˇˇˇ P ° ñ x ° d drw2 : ° d drw2 : $ ° d 4drw2 : ° ö ˇ˚Ä E¿ † ò
( {ïDeveloper Support † ô ° d drw2 : °„ † ó ° d `drw2 - Ô ˇˇˇˇˇˇ K Ô - Z f f Z ° d 1drw2 ¿˙È ˇˇˇˇˇˇ K ° ñ x ° d drw2 : ° d drw2 : $ ° d 4drw2 : 0 ° ö ˇÙ Ä † ò
0 ( UÔ † ô ° d drw2 : °„ † ó ° d 1drw2 ÔÊ˙ ˇˇˇˇˇˇ ° ñ x ° d drw2 : ° d drw2 : $ ° d 4drw2 : ° ö ˇ˝Ä † ò
+& ® † ô ° d drw2 : °„ † ó ° d 1drw2  -¯ y ˇˇˇˇˇˇ ° ñ x ° d drw2 : ° d drw2 : $ ° d 4drw2 : ° ö ˇ˚Ä % † ò
( Z \ Macintosh † ô ° d drw2 : °„ † ó † ç ° d drw2 D † É
IR . ° d ONLN d z < ç„ ( ß Z1Accessing the Script Manager Print Action Routine
° d ONLN d 2 å < õ Z *Text ° d ONLN d 8 åÖ õ˛ ( ∑£M.TE.PrintAction
° d ONLN d I ß < ≥ t ( œ Z Revised by: ° d ONLN d V ß≈ ≥˛ ( œ„
March 1988 ° d ONLN d a ≥ < ø q ( € Z Written by: ° d ONLN d m ≥ Ñ ø ª )H
Mark Davis ° d ONLN d x ≥± ø˛ ( €œ
November 1987 ° d ONLN d Ü À < ◊ ö ( Û ZThis technical note ° d ONLN d ö À ö ◊˛ )^Fdescribes how Print Drivers can access the Script Manager Print Action ° d ONLN d · ◊ < „k ( ˇ ZAroutine to print unconventional text, such as Japanese or Arabic. X
° d ONLN d# < ö *4
General Notes
° d ONLN d1# </ ∑ *Scripts such as Japanese ° d ONLN dJ# ∑/˛ ){?or Arabic modify the normal QuickDraw text handling in order to ° d ONLN dä0 << p (X Z
represent ° d ONLN dî0 p<≤ )47text properly. On the screen, this is done by trapping ,
Courier ° d ONLN dÀ/≤;„ (X–StdText ° d ONLN d“0„<˛ )1 and ° d ONLN d◊< <H ó (e Z
, which in ° d ONLN dY" <. (J Z)turn call QuickDraw internally to put up ° d ONLN dÇ".˛ )Ã/status messages on the screen. The Print Action ° d ONLN d≤. <: n (V Z
procedure ° d ONLN dº. n:˙ )2Thandles the text properly so that the text transformations are enabled during the re ° d ONLN d.˙:˛ (V- ° d ONLN d: <F{ (b ZFentrant calls, so that the status messages will be properly formatted.
° d ONLN dX^ <mA *'%When To Call the Print Action Routine
´Â )?/ record, saving the original routine addresses. ◊ X◊
(Ï Z1Accessing the Script Manager Print Action Routine (Ï1 ) of 3 ˇ ° ¿Ù%%DSIDICT:_cv
currentdict /bu known {bu}if
userdict /_cv known not{userdict /_cv 30 dict put}if
_cv begin
/bdf{bind def}bind def
currentscreen/cs exch def/ca exch def/cf exch def
/setcmykcolor where{/setcmykcolor get /cvcmyk exch def}{/cvcmyk{1 sub 4 1 roll 3{3 index add neg dup 0 lt{pop 0}if 3 1 roll}repeat setrgbcolor pop}bdf }ifelse
/ss{//cf //ca //cs setscreen}bdf
/stg{ss setgray}bdf
/strgb{ss setrgbcolor}bdf
/stcmyk{ss cvcmyk}bdf
/min1{dup 0 eq{pop 1}if}bdf
end
currentdict /bn known {bn}if
† øt ◊# ˇ ˇˇˇˇ # ◊
IR , Times
. +6-Macintosh Technical Notes / 4 /˘
° d ONLN d ) 5“ *$_The Print Action routine will actually call a Print Action routine for each script system that ° d ONLN d _ )“ 5⁄ ( Qis ° d ONLN d b 5 A » ( ] 6(currently installed. Each of the script ° d ONLN d ä 5 » A⁄ )∞;Print Action routines will do the appropriate tasks for its ° d ONLN d Δ A M = ( i 6system.
° d ONLN d Œ e t Ò *' Calling the Print Action Routine
° d ONLN d Ô Ä åq *KTo call the Print Action routine, the driver should use the following code: ,
Courier
° d ONLN d; ò £ O * intlGlobals ° d ONLN dG ò ` £ o )Hequ ° d ONLN dK ò Ñ £ ò )$$ba0 ° d ONLN dP ò ® £ )$; international globals ° d ONLN dh ¢ ≠ ^ ( … 6printActionOff ° d ONLN dw ¢ Ñ ≠ ì )lequ ° d ONLN d{ ¢ ® ≠ ∑ )$$16 ° d ONLN d ¢ Ã ≠l )$ ; offset to PrintAction proc ptr ° d ONLN d¢ ∂ ¡ ≥ ( › 6 ; get procedure pointer to call ° d ONLN d≈ < ’ U +$tst.w ° d ONLN dÀ ` ’ y )$Rom85 ° d ONLN d‘ ’Å )ê ; on a Macintosh + or better? ° d ONLN dÛ ‘ < fl U ( ˚ Zblt.s ° d ONLN d˘ ‘ ` fl ∞ )$@PrintActionDone ° d ONLN d ‘ fl" )ê
; no, skip ° d ONLN d fi < È Z ( Zmove.l ° d ONLN d fi ` È ¶ )$intlGlobals,d2 ° d ONLN d. fi Èw )ê get international globals ° d ONLN dK Ë < Û U ( Zble.s ° d ONLN dQ Ë ` Û ∞ )$@PrintActionDone ° d ONLN dc Ë ÛE )ê; not there, skip ° d ONLN dv Ú < ˝ Z ( Zmove.l ° d ONLN d} Ú ` ˝ y )$d2,a0 ° d ONLN dÜ Ú ˝Y )ê; in address register ° d ONLN dù ¸ < Z (# Zmove.l ° d ONLN d§ ¸ ` … )$printActionOff(a0),d2 ° d ONLN d∫ ¸ r )ê; get print action address ° d ONLN d÷ < U (- Zbeq.s ° d ONLN d‹ ` ∞ )$@PrintActionDone ° d ONLN dÓ E )ê; not there, skip ° d ONLN d < Z (7 Zmove.l ° d ONLN d ` y )$d2,a0 ° d ONLN d Y )ê; in address register ° d ONLN d)$ / ö (K 6; set up arguments to call ° d ONLN dG8 <C Z +$move.l ° d ONLN dN8 `C ó )$ <myPort>,d0 ° d ONLN d\8 C; )ê; pass the port ° d ONLN dmB <M Z (i Zmove.w ° d ONLN dtB `M ó )$ <myVerb>,d1 ° d ONLN dÇB M; )ê; pass the verb ° d ONLN dìL <W K (s Zjsr ° d ONLN dóL `W t )$(a0) ° d ONLN düL WT )ê; call the procedure ° d ONLN d¥V a h (} 6@PrintActionDone
° d ONLN d≈x á œ *&Print Action Routine Verbs
° d ONLN d‡ì üM *DThere are currently three verbs to pass to the Print Action routine.
° d ONLN d&´ <∂ x +$ paUnwindText ° d ONLN d4´ ®∂ ∑ )lequ ° d ONLN d8´ Ã∂ ÷ )$–1 ° d ONLN d<µ <¿ s (‹ Z paSpoolText ° d ONLN dIµ ®¿ ∑ )lequ ° d ONLN dMµ ÿ — )$1 ° d ONLN dPø < } (Ê Z
paNoQuickDraw ° d ONLN d_ø ® ∑ )lequ ° d ONLN dcø Ã — )$3
6Mprocedure receives the text. This verb is used when playing back stored text ° d ONLN d‚çÓ⁄ (
´that has already ° d ONLN dÓ ˙ n ( 6been transformed. ° d ONLN d* ~ *The other two verbs ( ° d ONLN d? ~ Ÿ )f
paNoQuickDraw ° d ONLN dL Ÿ ‹ )[ ° d ONLN dM ‹ Ò )and ° d ONLN dQ Ò> ) paSpoolText ° d ONLN d\>⁄ )M") are used to ensure that the text ° d ONLN d ô (< 6is transformed before your ° d ONLN dö ô )ÅStdText ° d ONLN d° 9 )1 procedure receives the ° d ONLN dπ9 h )o
text. The ° d ONLN d√h µ )/ paSpoolText ° d ONLN dŒµ ⁄ )M verb is ° d ONLN d◊! - N (I 6
used when ° d ONLN d·! N-à )6Ayour driver will use QuickDraw to image the text in the printing ° d ONLN d" à,¿ (I¶grafPort ° d ONLN d*!¿-⁄ )8. The ° d ONLN d0- 9 s (V 6
paNoQuickDraw ° d ONLN d=. s: ∂ )[ verb is used ° d ONLN dK. ∂:⁄ )C:when the text is not drawn into the printing port by going ° d ONLN dÜ: F (b 62through QuickDraw (e.g. the LaserWriter). In that ° d ONLN d∏:F⁄ ))case some languages (e.g. Japanese) which ° d ONLN d‚G SL (o 6Duse an extended font structure may need to recast the text calls as ° d ONLN d&FLRÑ (ojCopyBits ° d ONLN d.GÑS† )8 calls. ° d ONLN d6_ kÖ (á 6IAs mentioned above, some applications may call QuickDraw from within the ° d ONLN d_Ök⁄ (á£driver, as when a ° d ONLN dël x · (î 6%status window is updated. During any ° d ONLN d∂k ·w< )…
StdTxtMeasure ° d ONLN d√l<xB )[ ° d ONLN dƒlBx⁄ ) calls in the driver during the ° d ONLN d„y Ö v (° 6application’s call to ° d ONLN d˘x vÑ ß )^StdText ° d ONLN d y ßÖ )1, the port is checked ° d ONLN dy Ö⁄ )b-against the printer port. If they match, then ° d ONLN dDÖ ë> (≠ 6@the text is not transformed. Otherwise, the text is transformed. ◊ 4◊˘
*?2 ) of 3 )Ó1Accessing the Script Manager Print Action Routine ˇú ◊# ˇ ˇˇˇˇ # ◊
IR , Times
. +Z-Developer Support Center ( -Ï
March 1988 / X /
° d ONLN d < )™ ( E ZOThe solutions adopted by the Print Action routine assume that the print driver ° d ONLN d O ™ )˛ ( E»does not measure ° d ONLN d ` * < 6 Â ( R Z$or draw text except within calls to ,
StdTxtMeasure ° d ONLN d ë *@ 6R )[ or ° d ONLN d ï )R 5É )StdText ° d ONLN d ú *É 6± )1
. If your ° d ONLN d ¶ *± 6˛ ).driver does text ° d ONLN d ∑ 6 < B– ( ^ ZUbuffering (as for line layout), make sure that any measurements are performed within ° d ONLN d 6– B˛ ( ^Ó these two ° d ONLN d B < N † ( j Zcalls. For example, ° d ONLN d* B † N˛ )dByou might buffer both the text and its screen width as measured by ° d ONLN dm N < Z v ( v Z
(Ï Z1Accessing the Script Manager Print Action Routine (Ï3 ) of 3 ˇÜ ◊# ˇ ˇˇˇˇ # ◊ ° d WORD S † å ° d WORD R… † Ç
/ Z Å#
0Ià:µú9 " { ˇˇˇˇˇˇˇˇ # † ƒ ° d
ONLN f ˛ † å ° d 1drw2 … -·_ Ä ˇˇˇˇˇˇ è ° ñ x ° d drw2 : ° d drw2 : $ ° d 4drw2 : ° ö ˇ˙ ó@ † ò , Times
. WIQkWIQk +]BNew Technical Notes † ô ° d drw2 : °„ † ó ° d 1drw2 eÙ Ä ˇˇˇˇˇˇ P ° ñ x ° d drw2 : ° d drw2 : $ ° d 4drw2 : ° ö ˇ˚Ä E¿ † ò
Ä ( {ïDeveloper Support † ô ° d drw2 : °„ † ó ° d `drw2 - Ô ˇˇˇˇˇˇ K Ô - Z f f Z ° d 1drw2 ¿˙È ˇˇˇˇˇˇ K ° ñ x ° d drw2 : ° d drw2 : $ ° d 4drw2 : 0 ° ö ˇÙ Ä † ò
0 ( UÔ † ô ° d drw2 : °„ † ó ° d 1drw2 ÔÊ˙ ˇˇˇˇˇˇ ° ñ x ° d drw2 : ° d drw2 : $ ° d 4drw2 : ° ö ˇ˝Ä † ò
l +& ® † ô ° d drw2 : °„ † ó ° d 1drw2  -¯ y ˇˇˇˇˇˇ ° ñ x ° d drw2 : ° d drw2 : $ ° d 4drw2 : ° ö ˇ˚Ä % † ò
BÄ ( Z \ Macintosh † ô ° d drw2 : °„ † ó † ç ° d drw2 D † É ° d WORD † ç
IR . ° d ONLN d { < é î ( ® Z
Safe cdevs
° d ONLN d ç < ú Z *Text ° d ONLN d çç ú˛ ( ∏´
M.TE.SafeCDEV
° d ONLN d ® < ¥ q ( – Z Written by: ° d ONLN d + ® Ñ ¥ ¡ )H John Harvey ° d ONLN d 7 ®¡ ¥˛ ( –fl August 1989 ° d ONLN d C ¿ < Ã{ ( Ë Z?This Technical Note describes a potential problem with Control ° d ONLN d Ç ¿{ Ã˛ ( ËôPanel devices (cdevs) that ° d ONLN d ù Õ < Ÿ a ( ı Zcontain ,
Courier ° d ONLN d • à a ÿ ô )%EditText ° d ONLN d ≠ Õ ô ŸI )8' fields and presents a way to avoid it. X ° d ONLN d ’ Ú < ˛ À ( Z The Control Panel chapter in ° d ONLN d Ú Ú À ˛ )èInside Macintosh ° d ONLN d Ú ˛å )R, Volume 5 describes, ° d ONLN d Úå ˛˛ )oin detail, how run-time ° d ONLN d0 ˛ <
n (& Z?errors are handled by the Control Panel and a cdev. There is, ° d ONLN do ˛n
˛ (&å however, a potential problem ° d ONLN då < ´ (3 Zwith cdevs that contain ° d ONLN d§
´ „ )oEditText ° d ONLN d¨ „ò )8( items that this chapter does not cover. ° d ONLN d’$ <0@ (L Z7When a cdev is called by the Control Panel, the cdev’s ° d ONLN d #@/j (L^'DITL' ° d ONLN d$j0£ )*
userdict /_cv known not{userdict /_cv 30 dict put}if
_cv begin
/bdf{bind def}bind def
currentscreen/cs exch def/ca exch def/cf exch def
/setcmykcolor where{/setcmykcolor get /cvcmyk exch def}{/cvcmyk{1 sub 4 1 roll 3{3 index add neg dup 0 lt{pop 0}if 3 1 roll}repeat setrgbcolor pop}bdf }ifelse
/ss{//cf //ca //cs setscreen}bdf
/stg{ss setgray}bdf
/strgb{ss setrgbcolor}bdf
/stcmyk{ss cvcmyk}bdf
/min1{dup 0 eq{pop 1}if}bdf
end
currentdict /bn known {bn}if
† øË ◊# ˇ ˇˇˇˇ # ◊
IR , Times
. +6-Macintosh Technical Notes / 4 /˘ † Ç † å
< V ˛ÿ
4 w Y ˙õ ò * J | Œƒ J Œ¬ w Y ˚ú ⁄ˇ¸ ê⁄
ô –⁄
ô p⁄
ôÔ˛ˆˇ ¿ˆ ÙˇÏ êı
< 0 ¿ Û
ôˈˇ ¿b 0 ` ÙˇÔˇı
`<|y≥Δc«√ΔÛ Ëˆˇ¿`ff1Δfd˛f ÙˇÏ pı
`ff1Üf√ÊffÛ fóˈˇ ¿`ff1ÜffgÊÙˇÓfpı
`ff1ÜfffÛ
ôˈˇ ¿bff1Üfff&ÙˇÏ pı
<<fÉΔÊcΔÛ 3˜Ô˛ˆˇ ¿ˆ ÙˇÏà ⁄ ⁄ 0⁄ 3 Ÿˇ 3 ⁄ˇ˝ô
˘ Â
˘ Â@\
ÿ˘ (Â T
¯˘ D Â
˘ ÇÂ
˘ Â@\
8˘
òÂ
x˘ É‹Â
˘ Ç ˇˇ ÇÂ@\ ò Ç ˛ Â à ˇà  ¯ Ä H Â@_w x ™®H ˇ¯Â Ä H ˇ¸Â ™ÄH 8 ˇ ¯ Ä H 8Â@]/ ® H 8 ¯ Ä H < ˇ ò ® H 8 f x Ä H 8Â@]ô ™ H 8 ¯ Ä H < à ¯ Ä H 8 à ¯ ˇà 8Â@\ 8 ÿ < à x 8 3 x 8Â@]ô à ˇ¯Â ò àú ô ÿ
¬Ç ¬Ç ° d ONLN dˇˇ +“This line is a result of _DialogSelect calling
† ô ° ö ˇ˜ f † ò ° d ONLN dˇˇ * _TEIdle † ô † ó † ç † É
IR ° d ONLN d Î î ˜^ ( ≤"Figure 1–Erroneous Insertion Point ° d ONLN d # (, 63So the Dialog Manager, knowing that it allocated a ,
Courier ° d ONLN d VJ )˙TEHandle ° d ONLN d ^J` )8 for ° d ONLN d c`⁄ )an item that was visible, ° d ONLN d } î (8 6goes merrily on its way ° d ONLN d ï î ⁄ )|?flashing the insertion point. The problem is not simply one of ° d ONLN d ’ ( Ä (D 6appearance. If a user ° d ONLN d Ï Ä(⁄ )hGhits a key, the Dialog Manager tries to process the key-down event just ° d ONLN d4) 5 C (Q 6
as if the ° d ONLN d>( C4 { )+EditText ° d ONLN dF) {5 √ )8 item was still ° d ONLN dV) √5⁄ )H:available, and this series of events causes a rather nasty ° d ONLN dë5 A 5 (] 6crash. ° d ONLN dòN Z{ *HFortunately, the solution for this problem is a very simple one. If an ° d ONLN d‡M{Y≥ (vôEditText ° d ONLN dËN≥Z∏ )8 ° d ONLN dÈN∏Z⁄ )item is ° d ONLN dÒ[ g [ (É 6hidden with a ° d ONLN dˇZ [f ° )C
_HideDItem ° d ONLN d [ °g § )F ° d ONLN d
[ §g⁄ )Acall, the Dialog Manager does not consider it active and will not ° d ONLN dLh tF (ê 6Atry to process key-down events for it. So if your cdev contains ° d ONLN dçgFs~ (êdEditText ° d ONLN dïh~t∂ )8
items, part ° d ONLN d¢h∂t⁄ )8of your ° d ONLN d™u Å Ÿ (ù 6+error handling should be to first hide the ° d ONLN d’t ŸÄ )¡EditText ° d ONLN d›uÅH )8 items with ° d ONLN dÈuHÅr )7
a call to ° d ONLN dÛtrÄ∏ )*
_HideDItem ° d ONLN d˝u∏Å⁄ )F before ° d ONLN dÇ é ú (™ 6 returning an error code or a ° d ONLN d"Å úç ± )ÑNIL ° d ONLN d%Ç ±é< ) as the cdev’s function result. ° d ONLN dE≤ æ Ç (⁄ 6Further Reference: › 4›˘ ° d ONLN dXø *À . +
• ° d ONLN dZø <À ç )Inside Macintosh ° d ONLN djø çÀ' )Q , Volume I, The Dialog Manager ° d ONLN dâÀ *◊ . (Û H• ° d ONLN dãÀ <◊ ç )Inside Macintosh ° d ONLN dõÀ ç◊/ )Q , Volume IV, The Dialog Manager ° d ONLN dª◊ *„ . (ˇ H• ° d ONLN dΩ◊ <„ ç )Inside Macintosh ° d ONLN dÕ◊ ç„! )Q , Volume V, The Control Panel ◊ 4◊˘
(Ï 62 ) of 2 (Ïà Safe cdevs ˇ ◊# ˇ ˇˇˇˇ # ◊ † Ç
/ Z Å#
0Ià:µú9 " { ˇˇˇˇˇˇˇˇ # † ƒ ° d
ONLN f ˛ † å ° d 1drw2 … -·_ Ä ˇˇˇˇˇˇ è ° ñ x ° d drw2 : ° d drw2 : $ ° d 4drw2 : ° ö ˇ˙ ó@ † ò , Times
. R… R… +]BNew Technical Notes † ô ° d drw2 : °„ † ó ° d 1drw2 eÙ Ä ˇˇˇˇˇˇ P ° ñ x ° d drw2 : ° d drw2 : $ ° d 4drw2 : ° ö ˇ˚Ä E¿ † ò
( {ïDeveloper Support † ô ° d drw2 : °„ † ó ° d `drw2 - Ô ˇˇˇˇˇˇ K Ô - Z f f Z ° d 1drw2 ¿˙È ˇˇˇˇˇˇ K ° ñ x ° d drw2 : ° d drw2 : $ ° d 4drw2 : 0 ° ö ˇÙ Ä † ò
0 ( UÔ † ô ° d drw2 : °„ † ó ° d 1drw2 ÔÊ˙ ˇˇˇˇˇˇ ° ñ x ° d drw2 : ° d drw2 : $ ° d 4drw2 : ° ö ˇ˝Ä † ò
+& ® † ô ° d drw2 : °„ † ó ° d 1drw2  -¯ y ˇˇˇˇˇˇ ° ñ x ° d drw2 : ° d drw2 : $ ° d 4drw2 : ° ö ˇ˚Ä % † ò
( Z \ Macintosh † ô ° d drw2 : °„ † ó † ç ° d drw2 D † É
IR . ° d ONLN d n < Å Û ( õ ZScript Manager Q&As
° d ONLN d Ä < è Z *Text ° d ONLN d Äa è˛ ( ´M.TX.ScriptMgr.Q&As
° d ONLN d . õ < ß t ( √ Z Revised by: ° d ONLN d : õ Ñ ß ˇ )HDeveloper Support Center ° d ONLN d S õ± ߲ ( √œ
November 1992 ° d ONLN d a ß < ≥ q ( œ Z Written by: ° d ONLN d m ß Ñ ≥ ˇ )HDeveloper Support Center ° d ONLN d Ü ßæ ≥˛ ( œ‹ October 1990 ° d ONLN d ì ø < À ⁄ ( Á Z This Technical Note contains a ° d ONLN d ≤ ø ⁄ À˛ )û9collection of Q&As relating to a specific topic—questions ° d ONLN d Ï À < ◊† ( Û ZGyou’ve sent the Developer Support Center (DSC) along with answers from ° d ONLN d3 À† ◊˛ ( Ûæthe DSC engineers. ° d ONLN dF ◊ < „ u ( ˇ Z
While DSC ° d ONLN dP ◊ u „˛ )9Lengineers have checked the Q&A content for accuracy, the Q&A Technical Notes ° d ONLN dù „ < Ô q ( Z don’t have ° d ONLN d® „ q Ô˛ )5Qthe editing and organization of other Technical Notes. The Q&A function is to get ° d ONLN d˙ Ô < ˚ Ÿ ( Z new technical information and ° d ONLN d Ô Ÿ ˚˛ )ù6updates to you quickly, saving the polish for when the ° d ONLN dO ˚ < (# Z,information migrates into reference manuals. ° d ONLN d| < k *:Q&As are now included with Technical Notes to make access ° d ONLN d∂k ˛ (;â to technical updates easier for ° d ONLN d÷ <+. (G Z/you. If you have comments or suggestions about ° d ONLN d .+˛ )Ú*Q&A content or distribution, please let us ° d ONLN d0+ <7 \ (S Zknow ° d ONLN d5+ \7˛ ) Iby sending an AppleLink to DEVFEEDBACK. Apple Partners may send technical ° d ONLN d7 <Ci (_ Z9questions about Q&A content to DEVSUPPORT for resolution. ° d ONLN dπO <[« *NNew Q&As and Q&As revised this month are marked with a bar in the side margin. "n Ü XÜ
° d ONLN dÄ <è÷ *48Using FormatXToStr and FormatStrToX with Pascal switches
° d ONLN dAè <õ b * Written: ° d ONLN dJè àõ ≤ )L12/10/90 ° d ONLN dSõ <ß Å (√ ZLast reviewed: ° d ONLN dbõ àß ¶ )L8/1/92 ° d ONLN di≥ <ø V (€ ZWhy ° d ONLN dm≥ Vø˛ )Pdo the FormatXToStr and FormatStrToX Script Manager routines stop working when I ° d ONLN dæø <À ‹ (Á Z use the Pascal -MC68881 switch? ° d ONLN dfiÀ <◊ N * ___ ° d ONLN d‚„ <Ô3 *0Regular SANE extended numbers are 10 bytes long ° d ONLN d„3Ô˛ )˜%while MC68881 extended numbers are 12 ° d ONLN d8Ô <˚÷ ( ZTbytes long, and the extra two bytes are right in the middle of every 68881 extended ° d ONLN dåÔ÷˚˛ (Ùnumber. ° d ONLN dî˚ <∑ (# ZEAppendix G “The SANE Library” in the Macintosh Programmer’s Workshop ° d ONLN dŸ˚∑˛ (#’ (MPW) Object ° d ONLN dÊ <c (/ Z;Pascal version 3.1 manual goes into detail about this. The ° d ONLN d!c˛ (/ÅFormatX2Str and FormatStr2X ° d ONLN d= < X (; Zparse ° d ONLN dC X ˛ ) Tthe extended number you pass them directly, and they can only parse 10-byte extended ° d ONLN dò <+fi (G ZXnumbers. Fortunately, you can still use the -mc68881 option with these routines as long ° d ONLN d fi+˛ (G¸as you ° d ONLN d˜+ <7 Ä (S Z convert any ° d ONLN d+ Ä7˛ )DBextended numbers to 80-bit extended numbers before passing them to ° d ONLN dF7 <CÌ (_ ZUFormatX2Str and FormatStr2X. The SANE.p unit has routines to do this called X96toX80 ° d ONLN dõ7ÌC˛ (_ and ° d ONLN düC <O‡ (k ZJX80toX96 (incorrectly documented as X96to80 and X80to96 in the MPW Object ° d ONLN dÈC‡O˛ (k˛Pascal ° d ONLN dO <[ § (w Zmanual). Because the ° d ONLN dO §[˛ )hFextended80 and extended96 types aren’t equivalent to the extended type ° d ONLN dL[ <g Y (É Zas far ° d ONLN dS[ Yg˛ ) Sas Object Pascal is concerned, you have to redeclare FormatX2Str and FormatStr2X to ° d ONLN dßg <s (è Z-take these types. You can do this as follows: ,
Courier
° d ONLN d’ <ä6 *2FUNCTION FormatX2Str80 (x: extended80; ° d ONLN d â <îO *
7 myCanonical: NumFormatString; ° d ONLN d @ì <û; *
3 partsTable: NumberParts; ° d ONLN d tù <®w *
? VAR outString: Str255): FormatStatus; ◊ X◊
*(Script Manager Q&As (Ï1 ) of 7 ˇ ° ¿Ù%%DSIDICT:_cv
currentdict /bu known {bu}if
userdict /_cv known not{userdict /_cv 30 dict put}if
_cv begin
/bdf{bind def}bind def
currentscreen/cs exch def/ca exch def/cf exch def
/setcmykcolor where{/setcmykcolor get /cvcmyk exch def}{/cvcmyk{1 sub 4 1 roll 3{3 index add neg dup 0 lt{pop 0}if 3 1 roll}repeat setrgbcolor pop}bdf }ifelse
/ss{//cf //ca //cs setscreen}bdf
/stg{ss setgray}bdf
/strgb{ss setrgbcolor}bdf
/stcmyk{ss cvcmyk}bdf
/min1{dup 0 eq{pop 1}if}bdf
end
currentdict /bn known {bn}if
† ø˙ ◊# ˇ ˇˇˇˇ # ◊
IR , Times
. +6-Macintosh Technical Notes / 4 /˘ ,
Courier
° d ONLN d ( « *# INLINE $2F3C,$8210,$FFE8,$A8B5; ° d ONLN d $ 1 < Ù *,FUNCTION FormatStr2X80 (source: Str255; ° d ONLN d Q ; F& *
6 myCanonical: NumFormatString; ° d ONLN d à E P
*
1 partsTable: NumberParts; ° d ONLN d ∫ O ZX *
@ VAR x: extended80): FormatStatus; ° d ONLN d ˚ Y d « *
# INLINE $2F3C,$8210,$FFE6,$A8B5;
° d ONLN d o {œ *`Call these routines instead of the originals. To call FormatX2Str80, all you have to do is this:
° d ONLN d°Ÿ ËX *.String2Date and Date2Secs conversion surprises
° d ONLN d–Ë Ù > * Written: ° d ONLN dŸË dÙ à )L9/17/91 ° d ONLN d·Ù ] ( 6Last reviewed: ° d ONLN dÙ d Ç )L8/1/92 ° d ONLN d˜ 4 (4 6;String2Date and Date2Secs treat all dates with the year 04 ° d ONLN d2 4⁄ (4R to 10 as 2004 to 2010 instead of ° d ONLN dS $ [ (@ 6
1904 to 1910. ° d ONLN da$ 0 * * ___ ° d ONLN de< H8 *@This is correct; the Script Manager treats two-digit years less ° d ONLN d•<8H⁄ (dV!than or equal to 10 as 20xx dates ° d ONLN d«H T n (p 6if the current year ° d ONLN d€H nT⁄ )VKis between 1990 and 1999, inclusive. Basically, it just assumes that you’re ° d ONLN d'T `O (| 6Dtalking about 1-20 years in the future, rather than 80-100 years in ° d ONLN dkTO`⁄ (|m the past. The same is true of ° d ONLN dâ` lh (à 6Itwo-digit 9x dates, when the current year is less than or equal to xx10. ° d ONLN d“`hl⁄ (àÜThus, in 2003, the date ° d ONLN dÍl x â (î 6returned when 3/7/94 ° d ONLN dˇl âx⁄ )q>is converted will be 1994, not 2094. This is all documented in ° d ONLN d>x Ñã († 6G“Worldwide Development: Guide to System Software,” available from APDA.
° d ONLN d < ) b ( E ZWritten: ° d ONLN d à ) ¨ )L11/6/91 ° d ONLN d ) < 5 Å ( Q ZLast reviewed: ° d ONLN d ) à 5 ¶ )L8/1/92 ° d ONLN d ' A < MW ( i Z7Using the Script Manager to convert numbers to strings ° d ONLN d ^ AW M˛ ( iu and vice versa, in any language, ° d ONLN d M < Y a ( u Zwhat’s ° d ONLN d Ü M a Y˛ )%Pthe best way to create the string to pass to FormatX2Str? Will strings using the ° d ONLN d ◊ Y < e+ ( Å Z4characters: “#” or “0” or “.” or “,” work no matter ° d ONLN d Y+ e˛ )Ô-what script is currently running, and if not, ° d ONLN d9 e < q Å ( ç Zwhat can I do? ° d ONLN dH q < } N * ___ ° d ONLN dL â < ï‘ *PThe number format string and canonical number format string mechanisms that you ° d ONLN dú â‘ ï˛ ( ±Úuse with ° d ONLN d• ï < ° ≤ ( Ω ZFormatX2Str and its kin ° d ONLN dΩ ï ≤ °˛ )vEis a strange design, for exactly the reason that you asked about. The ° d ONLN d ° < ≠W ( … Z:number format string (the one with the characters such as ° d ONLN d= °W ≠˛ ( …u!“#” and “0”) does not necessarily ° d ONLN d_ ≠ < π> ( ’ Z6work right regardless of the current script. In fact, ° d ONLN dï ≠> π˛ ( ’\&it doesn’t even necessarily work right ° d ONLN dº π < ≈ ( · Z-between localized versions within one script ° d ONLN dÈ π ≈˛ )”/system. The canonical number format string does ° d ONLN d ≈ < —} ( Ì Z?work between localized systems and between script systems. The ° d ONLN dX ≈} —˛ ( Ìõstrange thing is there’s an ° d ONLN dt — < ›£ ( ˘ ZLeasy way to store number format strings (usually in a 'STR ' resource), but ° d ONLN d¿ —£ ›˛ ( ˘¡no obvious way to ° d ONLN d“ › < ÈW ( Z7store canonical number format strings. Here’s what you ° d ONLN d ›W È˛ (u can do when converting between ° d ONLN d( È < ı ü ( Znumbers and strings: ° d ONLN d= <
Ø *LWhen you convert a number format string to a canonical number format string ° d ONLN dâØ
õwant to provide the utility ° d ONLN d ∏Ò <˝ ™ ( Zthat converts a number ° d ONLN d œÒ ™˝˛ )nGformat string to a canonical number format string resource just in case ° d ONLN d
˝ < Ï (% Z&they have to change the entire format ° d ONLN d
=˝ Ï ˛ )∞7of the string. Then they can install the new 'NUMF' (or ° d ONLN d
u <r (1 ZBwhatever you choose) resource as part of the localization process.
° d ONLN d
∏- <<Ö *'1Code for truncating a multi-byte character string
° d ONLN d
Í< <H b * Written: ° d ONLN d
Û< àH ¨ )L1/24/92 ° d ONLN d
˚H <T Å (p ZLast reviewed: ° d ONLN d
H àT ¶ )L8/1/92 ° d ONLN d ` <le (à Z=I create a Macintosh file name from another file name. Since ° d ONLN d N`el˛ (àÉ I am adding information to the ° d ONLN d ml <xÅ (î Z>name, I must make sure that it is within the 31 chars maximum ° d ONLN d ´lÅx˛ (îüallowed by the operating ° d ONLN d ƒx <Ñ († Z)system. What I need is the equivalent of ° d ONLN d ÌxÑ˛ )»0the TruncText command, except instead of dealing ° d ONLN d Ñ <ê. (¨ Z3with pixel width, I want the width to be number of ° d ONLN d QÑ.ê˛ )Ú,characters (31). I can trunc myself, but I’d ° d ONLN d ~ê <úë (∏ ZHrather do a proper “smTruncMiddle” and have it nicely internationalized. ° d ONLN d «ú <® N * ___ ◊ X◊
*(Script Manager Q&As (Ï3 ) of 7 ˇö ◊# ˇ ˇˇˇˇ # ◊
IR , Times
. +6-Macintosh Technical Notes / 4 /˘
° d ONLN d ) 5N *$CIf you’re going to be adding a set number of bytes to the end of a ° d ONLN d C )N 5⁄ ( Ql existing string and you don’t ° d ONLN d a 5 AG ( ] 6?want the localized ellipsis (from the 'itl4' resource) between ° d ONLN d † 5G A⁄ ( ]e the truncated string and your ° d ONLN d æ A M ¬ ( i 6%bytes, then you can use this routine: ,
Courier
° d ONLN d ‰ Y dg *CPROCEDURE TruncPString (VAR theString: Str255; maxLength: Integer); ° d ONLN d( c nÖ *
I{ This procedure truncates a Pascal string to be of length maxLength or } ° d ONLN dr m xv *
F{ shorter. It uses the Script Manager charByte function to make sure } ° d ONLN dπ w Çq *
E{ the string is not broken in the middle of a multi-byte character. } ° d ONLN dˇ Å å 1 *
° d ONLN dò % î *If you want the localized ° d ONLN d≤ î%⁄ )|Dellipsis (from the 'itl4' resource) between the truncated string and ° d ONLN d˜% 1L (M 6Dyour bytes, or you want the localized ellipsis in the middle of the ° d ONLN d;%L1⁄ (Mj combined strings truncated to ° d ONLN dY1 = ı (Y 61a specific length, then you can use this routine:
° d ONLN dãI T] *AFUNCTION TruncPString (maxLength: Integer; VAR theString: Str255; ° d ONLN dŒS ^ ∏ *
truncWhere: TruncCode): Integer; ° d ONLN dÔ] hÄ *
H{ This function truncates a Pascal String to be of length maxLength or } ° d ONLN d8g r{ *
G{ shorter. It uses the Script Manager TruncString function which adds } ° d ONLN dÄq |q *
E{ the correct tokenEllipsis to the middle or end of the string. See } ° d ONLN dΔ{ Üg *
C{ Inside Macintosh Volume VI, pages 14-59 and14-60 for more info. } ° d ONLN d
1 IF whatHappened < smNotTruncated THEN ° d ONLN dÇ9 D Ô *
+ BEGIN { ERROR, bail out now } ° d ONLN dÆC NN *
> TruncPString := whatHappened; { return error } ° d ONLN dÌM X « *
# Exit(TruncPString); ° d ONLN d W b m *
END ° d ONLN d #a l+ *
7 ELSE IF Length(tempString) = maxLength THEN ° d ONLN d [k v ü *
found := TRUE ° d ONLN d wu Ä+ *
7 ELSE IF Length(tempString) > maxLength THEN ° d ONLN d Ø ä ¬ *
" last := midPoint - 1 ° d ONLN d “â î h *
ELSE ° d ONLN d „ì û Ã *
$ first := midPoint + 1; ° d ONLN d
ù ® ^ *
END; ◊ 4◊˘
*(4 ) of 7 (ÏûScript Manager Q&As ˇ
> ◊# ˇ ˇˇˇˇ # ◊
IR , Times
. +Z-Developer Support Center ( -‹
November 1992 / X / ,
Courier
° d ONLN d < ( ‹ ( D Z theString := tempString; ° d ONLN d ! ' < 2ê *
D TruncPString := whatHappened; { will always be smTruncated } ° d ONLN d f 1 < <J *
6 { in this case } ° d ONLN d ù ; < F i *
END ° d ONLN d ß E < P d *
ELSE ° d ONLN d ∞ O < Zê *
D TruncPString := smNotTruncated; { the string wasn't too long } ° d ONLN d ı Y < d Z *
END;
° d ONLN d ¸ { < ä¡ *&9Character type and subtype values within the Kanji system
° d ONLN d6 ä < ñ b * Written: ° d ONLN d? ä à ñ ≤ )L11/17/89 ° d ONLN dH ñ < ¢ Å ( æ ZLast reviewed: ° d ONLN dW ñ à ¢ ¶ )L8/1/92 ° d ONLN d^ Æ < ∫» ( ÷ ZRWhat are the values of character type and subtype with the Macintosh Kanji system? ° d ONLN d± ∫ < Δ N * ___ ° d ONLN dµ “ < fi( *2For Roman, these are the values of character type:
° d ONLN dË Í < ı π * Punctuation 0 ° d ONLN d Ù < ˇ π *
ASCII 1 ° d ONLN d ˛ < π *
European 7
° d ONLN d6 < ä *FFor KanjiTalk, the values are the same as Roman, with the addition of:
° d ONLN d}, <7 π * Katakana 2 ° d ONLN dó6 <A π *
Hiragana 3 ° d ONLN d±@ <K π *
Kanji 4 ° d ONLN dÀJ <U π *
Greek 5 ° d ONLN dÂT <_ π *
Russian (Cyrillic) 6
° d ONLN dˇj <v *.In Roman, the subtype field is interpreted as:
° d ONLN d.Ç <ç π * Normal punctuation 0 ° d ONLN dHå <ó π *
Numeric 1 ° d ONLN dbñ <° π *
Symbols 2 ° d ONLN d|† <´ π *
Blanks 3
° d ONLN dñ∂ <¬ É *The KanjiTalk ° d ONLN d§∂ ɬ˛ )GNsubtype values are the same as Roman except if the character type is Kanji, in ° d ONLN dÛ¬ <Œ (Í Z0which case the subtype field takes these values:
° d ONLN d$⁄ <Â π * JIS Level 1 0 ° d ONLN d>‰ <Ô π *
JIS Level 2 1 ° d ONLN dXÓ <˘ π *
JIS User Character 2
° d ONLN dr <˜ *_Finally, for KanjiTalk, the character direction field is replaced by the In-ROM field. It is 1 ° d ONLN d—˜˛ (,if ° d ONLN d‘ < % (8 Z1the character is in the ROM card and 0 otherwise. ◊ X◊
*¥Script Manager Q&As (Ï5 ) of 7 ˇ ◊# ˇ ˇˇˇˇ # ◊
IR , Times
. +6-Macintosh Technical Notes / 4 /˘
° d ONLN d ) 8[ *'-Script Manager NMeasureJust documentation fix
° d ONLN d . 8 D > * Written: ° d ONLN d 7 8 d D à )L7/21/92 ° d ONLN d ? D P ] ( l 6Last reviewed: ° d ONLN d N D d P à )L9/15/92 ° d ONLN d V \ h N ( Ñ 6 The Script ° d ONLN d a \ N h⁄ )6KManager’s NMeasureJust call seems to work differently depending on our main ° d ONLN d ≠ h t ≠ ( ê 6 script (Roman versus Hebrew, ° d ONLN d h ≠ t⁄ )ï?for example). Please take a look at the following code and tell ° d ONLN d
t Ä ª ( ú 6 me if I’m doing something wrong: ,
Courier
° d ONLN d+ å ó *{ ° d ONLN d- ñ ° ; *
.... ° d ONLN d5 † ´ w *
Fixed slop = 0; ° d ONLN dI ™ µ ü *
Point numer = {1,1}; ° d ONLN de ¥ ø ü *
Point denom = {1,1}; ° d ONLN dÅ æ …è *
K ::NMeasureJust ((Ptr) charBuffer, (short) charCount,slop,(Ptr) charLocs, ° d ONLN dÕ » ”! *
5 smOnlyStyleRun, numer, denom); ° d ONLN d “ › Å *
if (charLocs[0]) { ° d ONLN d ‹ Áô *
M // Under Hebrew system NMeasureJust acts differently than described in ° d ONLN dg Ê Ò∑ *
S // Inside Macintosh Volume VI; first entry in charLocs array containes width ° d ONLN dª ˚î *
L // of last character and last entry in charLocs array containes zero. ° d ONLN d ˙ Â *
) charLocs[charCount] = charLocs[0]; ° d ONLN d2 ã *
charLocs[0] = 0; ° d ONLN dJ 1 *
}; ° d ONLN dP # ; *
.... ° d ONLN dX" - *
}
° d ONLN dZ, 8 * * ___ ° d ONLN d^D P ≈ *#The truth is that Inside Macintosh ° d ONLN dÅD ≈P⁄ )≠3Volume VI is incorrect, and NMeasureJust is working ° d ONLN dµP \ ñ (x 6correctly, even though the ° d ONLN d–P ñ\⁄ )~?results seem to defy any kind of sense. Here’s how NMeasureJust ° d ONLN d\ h 9 (Ñ 6works: ° d ONLN dt Ä _ *
NMeasureJust ° d ONLN d$t _Ä⁄ )GRactually puts into the first entry of the charLocs array the pixel offset from the ° d ONLN dwÄ å + (® 6left ° d ONLN d|Ä +å⁄ )[end of the text to the leading edge of the first character, regardless of the active script ° d ONLN dÿå ò y (¥ 6system. For Roman ° d ONLN dÍå yò⁄ )aHtext in a Roman script system, that’s easy: it’s always zero. For Hebrew ° d ONLN d3ò §x (¿ 6Ntext in a Hebrew script system, the leading edge of the first character is on ° d ONLN dÅòx§⁄ (¿ñthe right edge of the ° d ONLN dó§ ∞V (à 6Dtext, so NMeasureJust puts the pixel distance between the left edge ° d ONLN d€§V∞⁄ (Ãt of the text to the right edge ° d ONLN d˘∞ ºΩ (ÿ 6Sof the text——the same thing as the entire width of the text. Each successive entry ° d ONLN dL∞Ωº⁄ (ÿ€in the ° d ONLN dSº »P (‰ 6@charLocs array is smaller than the previous entry because we’re ° d ONLN dìºP»⁄ (‰n gradually moving to the left ° d ONLN d∞» ‘ ( 64edge of the text as we move through each successive ° d ONLN d‰» ‘⁄ (;(character. The trailing edge of the last ° d ONLN d
‘ ‡¡ (¸ 6acharacter is at the left edge of the string, and so the last entry in the charLocs array is zero. ° d ONLN doÏ ¯v *CWhat if you pass in text that contains both Roman and Hebrew text? ° d ONLN d≤Ïv¯⁄ (îThis text contains a ° d ONLN d«¯ » ( 6Vdirection boundary, and NMeasureJust can sense this. For this case, NMeasureJust puts ° d ONLN d ¯»⁄ ( Êinto ° d ONLN d" ò (, 6 the charLocs array a series ° d ONLN d> ò⁄ )ÄFof decreasing values for the right-to-left characters, and a series of ° d ONLN dÖ ˙ (8 63increasing values for the left-to-right characters. ° d ONLN dπ( 4i *BYou’re probably passing Roman text (ASCII codes less than 127) to ° d ONLN d˚(i4⁄ (PáNMeasureJust with the ° d ONLN d 4 @ b (\ 6Hebrew script ° d ONLN d 4 b@⁄ )JJsystem active to get the results that you reported. This case includes two ° d ONLN d j@ L> (h 6@direction boundaries: one at the beginning that’s right-to-left ° d ONLN d ™@>L⁄ (h\ and contains no characters, one ° d ONLN d L X6 (t 6=that’s left-to-right and contains all your Roman characters, ° d ONLN d
L6X⁄ (tT$and finally one that’s right-to-left ° d ONLN d
,X d · (Ä 6,and contains no characters. The first entry ° d ONLN d
XX ·d⁄ )…6in the charLocs array measures the first right-to-left ° d ONLN d
èd p ù (å 6 direction run even though it ° d ONLN d
¨d ùp⁄ )ÖDcontains no characters, and so it contains the position of the right ° d ONLN d
Òp |ö (ò 6Tedge of your text. The last entry in the charLocs array is zero because it measures ° d ONLN d Epö|÷ (ò∏the last right ° d ONLN d Sp÷|⁄ )<- ° d ONLN d T| à c (§ 6to-left direction ° d ONLN d f| cà⁄ )KMrun, which again contains no characters. All the charLocs entries between the ° d ONLN d ¥à î ‹ (∞ 6,first and the last measure the positions of ° d ONLN d ‡à ‹î⁄ )ƒ5the left-to-right, Roman characters, and so you get a ° d ONLN d î † Ÿ (º 6*series of increasing values. This is just ° d ONLN d @î Ÿ†⁄ )¡6a special case of passing text that contains direction ° d ONLN d w† ¨ £ (» 6boundaries to NMeasureJust. ◊ 4◊˘
° d ONLN d 5 < D∫ ( ` Z6Interfacing a Macintosh application with Map CDEV data " T W
° d ONLN d 7 D < P b * Written: ° d ONLN d @ D à P ¨ )L8/17/92 " c W ° d ONLN d H P < \ Å ( x ZLast reviewed: ° d ONLN d W P à \ ≤ )L10/11/92 " o W " { W ° d ONLN d ` h < t ú ( ê ZHow can I provide ° d ONLN d r h ú t˛ )`Emy users with a “hook” to access the geographical database in Apple’s " á W ° d ONLN d ∏ t < Ä ( ú Z(“Map” Control Panel from my application? " ì W ° d ONLN d · Ä < å N * ___ " ü W " ´ W ° d ONLN d  ò < § “ * There’s no supported way of ° d ONLN d ò “ §˛ )ñ:accessing the geographical database contained in the “Map” " ∑ W ° d ONLN d< § < ∞§ ( à ZMControl Panel. Here are some hints, however (just to satisfy your curiosity): " √ W " œ W ° d ONLN dä º < »† *GThe data are stored in a resource of type 'CTY#', ID=-4064, in the Map ° d ONLN d— º† »˛ ( ‰æcdev. The resource " € W ° d ONLN d‰ » < ‘ ´ ( Zformat is a list of word ° d ONLN d˝ » ´ ‘˛ )oIaligned (variable length) city entries, preceded by an integer indicating " Á W ° d ONLN dG ‘ < ‡ ( ¸ Z0the number of entries. Each entry has the format " Û W " ˇ W ° d ONLN dx Ï < ¯ Ú ** [Integer] length in bytes of the entry " W ° d ONLN d§ ¯ < Ò * ) [Longint] latitude in Fract; north = + " W ° d ONLN dŒ < Ù * ) [Longint] longitude in Fract; east = + "# W ° d ONLN d¯ < " * 0 [Longint] GMT difference in seconds; east = + "/ W ° d ONLN d) <( * [Longint] (reserved; set to 0) "; W ° d ONLN dJ( <4 ◊ * " [PascalString] name of the city. "G W ◊ X◊
ONLN f ˛ † å ° d 1drw2 … -·_ Ä ˇˇˇˇˇˇ è ° ñ x ° d drw2 : ° d drw2 : $ ° d 4drw2 : ° ö ˇ˙ ó@ † ò , Times
. R… R… +]BNew Technical Notes † ô ° d drw2 : °„ † ó ° d 1drw2 eÙ Ä ˇˇˇˇˇˇ P ° ñ x ° d drw2 : ° d drw2 : $ ° d 4drw2 : ° ö ˇ˚Ä E¿ † ò
( {ïDeveloper Support † ô ° d drw2 : °„ † ó ° d `drw2 - Ô ˇˇˇˇˇˇ K Ô - Z f f Z ° d 1drw2 ¿˙È ˇˇˇˇˇˇ K ° ñ x ° d drw2 : ° d drw2 : $ ° d 4drw2 : 0 ° ö ˇÙ Ä † ò
0 ( UÔ † ô ° d drw2 : °„ † ó ° d 1drw2 ÔÊ˙ ˇˇˇˇˇˇ ° ñ x ° d drw2 : ° d drw2 : $ ° d 4drw2 : ° ö ˇ˝Ä † ò
+& ® † ô ° d drw2 : °„ † ó ° d 1drw2  -¯ y ˇˇˇˇˇˇ ° ñ x ° d drw2 : ° d drw2 : $ ° d 4drw2 : ° ö ˇ˚Ä % † ò
( Z \ Macintosh † ô ° d drw2 : °„ † ó † ç ° d drw2 D † É
IR . ° d ONLN d z < ç ( ß ZScript Manager Variables
° d ONLN d å < õ Z *Text ° d ONLN d åå õ˛ ( ∑™M.TE.ScriptVars
° d ONLN d / ß < ≥ q ( œ Z Written by: ° d ONLN d ; ß Ñ ≥
)HJohn Harvey & Peter Edberg ° d ONLN d V ßÕ ≥˛ ( œÎ June 1989 ° d ONLN d ` ø < À¶ ( Á ZPThis Technical Note describes, in detail, the local and global script variables. ˆ X ˆ
° d ONLN d ± < ˇ è *4 Introduction
° d ONLN d æ <( *0The Script Manager maintains a number of global ° d ONLN d Ó (˛ )Ï,variables which can be read with the routine ,
Courier ° d ONLN d <# ê (@ Z _GetEnvirons ° d ONLN d' ê$ ö )T. ° d ONLN d* ö$¶ )
7These variables can be set by a corresponding routine, ° d ONLN da¶#˙ (@ƒ _SetEnvirons ° d ONLN dm˙$˛ )T. ° d ONLN dp$ <0 é (L ZIn addition, each ° d ONLN dÇ$ é0˛ )RNscript interface system maintains variables of its own. These are referred to ° d ONLN d—0 <<~ (X ZAas local variables in Inside Macintosh, Volume V-293, The Script ° d ONLN d0~<˛ (XúManager, and are read by ° d ONLN d+< <H Ç (e Z
_GetScript ° d ONLN d5= ÇI ∏ )F and set by ° d ONLN dA< ∏H ˛ )6
_SetScript ° d ONLN dK= ˛I )F. ° d ONLN dMU <a ◊ (} Z#Think of it like this: the Script ° d ONLN dpU ◊a˛ )õ:Manager maintains an environment in which different script ° d ONLN d´a <m (â Z.interfaces can run. The global variables are ° d ONLN dŸa m˛ )–1used to set up and maintain the environment (thus ° d ONLN d n <z Ç (ñ Zthe names for ° d ONLN dn Çz ¿ )F
the routines ° d ONLN d&m ¿y )> _GetEnvirons ° d ONLN d2nz/ )T and ° d ONLN d7m/yÉ ) _SetEnvirons ° d ONLN dCnÉz˛ )T), and the local variables ° d ONLN d^{ <á (£ Z0control how the script itself works (so we have ° d ONLN déz Üc )·
_GetScript ° d ONLN dò{cáz )F and ° d ONLN dùzzÜ¿ )
_SetScript ° d ONLN dß{¿á» )F).
° d ONLN d™ü <Æ ¨ ( ZGlobal Variables
° d ONLN dªª <« è *When you call ° d ONLN d…∫ èΔ „ )S _GetEnvirons ° d ONLN d’ª „« ˚ )T or ° d ONLN dŸ∫ ˚ΔA )
_GetScript ° d ONLN d„ªA«ì )F, you describe ° d ONLN dÚªì«˛ )Rthe variable you are ° d ONLN d« <” ¬ (Ô Z interested in with a verb. A ° d ONLN d%« ¬”˛ )Ü@verb is simply an integer constant which the Script Manager uses ° d ONLN df” <fl (˚ Z1to figure out which variable you want to read or ° d ONLN dó” fle )‰set. The z in ° d ONLN d¶”efl∑ )EInside Macintosh ° d ONLN d∂”∑fl˛ )R, V-313, gives ° d ONLN d≈‡ <Ï £ ( Zincorrect names and ° d ONLN dŸ‡ £Ï9 )g descriptions for some of the ° d ONLN dˆfl9Îç )ñ _GetEnvirons ° d ONLN d‡çÏ™ )T and ° d ONLN dfl™Î˛ ) _SetEnvirons ° d ONLN dÏ <¯ ( Z.verbs. Table 1 provides correct descriptions. ◊ X◊
*ÿScript Manager Variables (Ïˇ1 ) of 10 ˇ ° ¿Ù%%DSIDICT:_cv
currentdict /bu known {bu}if
userdict /_cv known not{userdict /_cv 30 dict put}if
_cv begin
/bdf{bind def}bind def
currentscreen/cs exch def/ca exch def/cf exch def
/setcmykcolor where{/setcmykcolor get /cvcmyk exch def}{/cvcmyk{1 sub 4 1 roll 3{3 index add neg dup 0 lt{pop 0}if 3 1 roll}repeat setrgbcolor pop}bdf }ifelse
/ss{//cf //ca //cs setscreen}bdf
/stg{ss setgray}bdf
/strgb{ss setrgbcolor}bdf
/stcmyk{ss cvcmyk}bdf
/min1{dup 0 eq{pop 1}if}bdf
end
currentdict /bn known {bn}if
† øƒ ◊# ˇ ˇˇˇˇ # ◊
IR , Times
. +6-Macintosh Technical Notes / 4 /˘
° d ONLN d ) < 5 n +$$Constant ° d ONLN d ) ü 5 ø )cValue ° d ONLN d ) fi 5 )?Meaning T X Tµ ,
Courier ° d ONLN d 6 < B { ( _ Z smVersion ° d ONLN d ! 7 ¨ C ≤ )p0 ° d ONLN d # 7 fi Cs )2 Script Manager version number ° d ONLN d A C < O t ( l ZsmMunged ° d ONLN d J D ¨ P ≤ )p2 ° d ONLN d L D fi PY )2Global modification count ° d ONLN d f P < \ { ( y Z smEnabled ° d ONLN d p Q ¨ ] ≤ )p4 ° d ONLN d r Q fi ]ä )2%Script count; 0 if Script Manager not ° d ONLN d ö ] fi i * enabled ° d ONLN d ¢ i < u Ç ( í Z
smKeyCache ° d ONLN d= ¨( ∏ )p26 ° d ONLN d@ fi(G )2[Obsolete, do not use] ° d ONLN dW( <4 { (Q Z smKeySwap ° d ONLN da) ¨5 ∏ )p28 ° d ONLN dd) fi5ã )2!Keyboard swapping resource handle ° d ONLN dÜA <M Ç (j Z
smGenFlags ° d ONLN dëB ¨N ∏ )p30 ° d ONLN dîB fiN )2
General flags ° d ONLN d¢N <Z Ç (w Z
smOverride ° d ONLN d≠O ¨[ ∏ )p32 ° d ONLN d∞O fi[> )2Script override flags ° d ONLN dΔ[ <g ó (Ñ Z
smCharPortion ° d ONLN d‘\ ¨h ∏ )p34 ° d ONLN d◊\ fihì )2%Ch vs Sp Extra proportion, 4.12 fixed á Xáµ ° d ONLN d˝u hÅâ (ù Ü/Table 1–Verbs for _GetEnvirons and _SetEnvirons ° d ONLN d-ô • à (¡ 6*The descriptions in the table are still a ° d ONLN dWô Õ⁄ )¥9bit sketchy. The next section describes each variable in ° d ONLN dë• ± ˛ (Õ 62more detail and describes the size of each global. ° d ONLN dƒæ ê *Byte or word globals are ° d ONLN d›æ ê n )x,mapped to the low-order byte or word of the ° d ONLN d Ωn…ü )fiLongInt ° d ONLN dæü ⁄ )1 returned by ° d ONLN d ÷ l (Û 6 _GetEnvirons ° d ONLN d)À l◊ó )T8, with the high-order parts set to zero. Similarly, for ° d ONLN daÀó◊⁄ (Ûµ
these globals ° d ONLN do◊ „ l ( 6 _SetEnvirons ° d ONLN d{ÿ l‰w )T9 ignores all but the appropriate part (low-order byte or ° d ONLN d¥ÿw‰⁄ ( ïword) of its params ° d ONLN d»‰ 5 ( 6value. ° d ONLN dœ¸ < { +$ Verb Name ° d ONLN dŸ¸ ® » )lBytes ° d ONLN dfl¸ R )HBrief Description ° d ONLN dÒ < { (= Z smVersion ° d ONLN d˚ ®! Æ )l2 ° d ONLN d˝ !Ö )H Script Manager version number ° d ONLN d. :/ (V 6=At boot time, the version global is initialized to the value ° d ONLN dX-/9g (VMSMgrVers ° d ONLN d`.g:⁄ )8. The high byte is the ° d ONLN dx: F õ (b 6major version number and ° d ONLN dë: õF⁄ )É?is defined in the MPW interface files. The low byte is updated ° d ONLN d—F R (n 60when any changes are made to the Script Manager. ° d ONLN d^ <j t +$smMunged ° d ONLN d _ ®k Æ )l2 ° d ONLN d
_ kk )HGlobal modification count ° d ONLN d'w É{ (ü 6KThe munged global is initialized to zero at boot time and incremented when: ° d ONLN dsÑ *ê . +
. +Z-Developer Support Center ( -Û June 1989 / X / ,
Courier
° d ONLN d ) ` 5 ü ( R ~ smEnabled ° d ONLN d
* à 6 “ )l1 ° d ONLN d * 6Á )H-Script count; 0 if Script Manager not enabled ° d ONLN d : B < N≈ ( j ZTAt boot time or switch-launch time, the enabled global is initialized to zero, then ° d ONLN d é B≈ N˛ ( j„ incremented ° d ONLN d ö N < Z ° ( v Zfor each script that is ° d ONLN d ≤ N ° Z˛ )eFinstalled and enabled. Since the Roman script system should always be ° d ONLN d ˘ Z < f˛ ( Ç Zbinstalled by the Script Manager, a value of zero indicates that the Script Manager is not enabled. ° d ONLN d\ s < b *=It should be noted that older versions of the Script Manager ° d ONLN dô sb µ ( õÄtreated this as a ° d ONLN d´ rµ ~Ê )SBoolean ° d ONLN d≤ sÊ ˛ )1. In ° d ONLN d∏ Ä < å ( ® Z(other words, if there was more than one ° d ONLN d‡ Ä å] )–script installed, ° d ONLN dÚ ] ã˛ )Q_GetEnvirons(smEnabled) ° d ONLN d
ç < ô ≤ ( µ Zwould return 255 (when ° d ONLN d! å ≤ ò )v _GetEnvirons ° d ONLN d- ç ô5 )T returns a ° d ONLN d8 å5 òf )/Boolean ° d ONLN d? çf ôÈ )1 value $FF represents true). ° d ONLN d\ • < ± ˘ ( Õ Z(For this reason, when testing to see if ° d ONLN dÑ • ˘ ±˛ )Ω8more than one script is installed, it is best to test as ° d ONLN dΩ ± < Ω c ( Ÿ Zfollows:
° d ONLN d« … ` ‘7 +$+scriptsinstalled := GetEnvirons(smEnabled); ° d ONLN dÙ ” ` fi Ï *
IF scriptsinstalled > 1 THEN ° d ONLN d › ` Ëd *
4{more than one script available, use Chartype, etc.}
° d ONLN dI Û ` ˇ ¶ *
smBidirect ° d ONLN dT Ù Ã “ )l1 ° d ONLN dV Ù Ç )HBidirectional script flag ° d ONLN dp < ⁄ (4 Z#The bidirectional global indicates ° d ONLN dì ⁄˛ )ûBthat at least one bidirectional script is installed. It should be ° d ONLN d÷ <$Ÿ (@ ZXset to true ($FF) by the Arabic and Hebrew script systems. This is not presently done, ° d ONLN d.Ÿ$˛ (@˜but will ° d ONLN d7$ <0 (L Z1be corrected in future versions of these systems. ° d ONLN di< `H ≠ +$ smFontForce ° d ONLN du= ÃI “ )l1 ° d ONLN dw=IZ )HForce font flag ° d ONLN dáI `U ≠ (r ~ smIntlForce ° d ONLN dìJ ÃV “ )l1 ° d ONLN dïJV¶ )H"Force international utilities flag ° d ONLN d∏V `b ò ( ~smForced ° d ONLN d¡W Ãc “ )l1 ° d ONLN d√Wc√ )H&Current script forced to system script ° d ONLN dÍc `o ü (å ~ smDefault ° d ONLN dÙd Ãp “ )l1 ° d ONLN dˆdp— )H(Current script defaulted to Roman script ° d ONLN d } <â } (• ZAt boot time, ° d ONLN d-| }à º )A FontForce ° d ONLN d6} ºâ ” )? and ° d ONLN d;| ”à ) IntlForce ° d ONLN dD}âa )? are set from the ° d ONLN dV|aàã )O'itlc' ° d ONLN d\}ãâ‘ )* resource, and ° d ONLN dk|‘à˛ )IForced ° d ONLN drä <ñ Q (≤ Zand ° d ONLN dvâ Qï Ç )Default ° d ONLN d}ä Çñz )16 are set to zero. These are all flags with the value ° d ONLN d≥äzñ˛ )¯zero for false and $FF for ° d ONLN dŒó <£ Z (ø Ztrue. ° d ONLN d‘ó Z£ c ) ° d ONLN d’ñ c¢ ¢ ) FontForce ° d ONLN dfió ¢£ ≈ )? and ° d ONLN d„ñ ≈¢ )# IntlForce ° d ONLN dÏó£≠ )? control the operation of the ° d ONLN d
the system ° d ONLN d”’ <·∞ (˝ ZQscript. This is for compatibility with applications that hard-code font numbers. ° d ONLN d%Ì <˘ { * IntlForce ° d ONLN d.Ó {˙ )? determines the behavior of the ° d ONLN dNÌ˘U )î
_IUGetIntl ° d ONLN dXÓU˙ï )F
call. When ° d ONLN deÌï˘‘ )@ intlforce ° d ONLN dnÓ‘˙˛ )?
is set to ° d ONLN dy˚ < U (# Ztrue, ° d ONLN d˙ U õ )
_IUGetIntl ° d ONLN dâ˚ õ )F will return a handle to ° d ONLN d¢˚≥ )m%the international resources (of type ° d ONLN d«˙≥› )´'itlx' ° d ONLN dÕ˚›˛ )* where ° d ONLN d‘ < C (0 Zx ° d ONLN d’ C ˙ )& is 0-2) for the system script. When ° d ONLN d˚ ˙9 )∑ IntlForce ° d ONLN d9y )? is false, the ° d ONLN dyø )@
_IUGetIntl ° d ONLN d ø˛ )F
will use the ° d ONLN d+ < º (< Z font of the current port to ° d ONLN dG º ˛ )ÄAdetermine the appropriate resources to fetch. Thus date formats, ° d ONLN dâ <, ˛ (H Z-sorting, etc. can reflect the current script. ° d ONLN d∑8 `D ë +$smPrint ° d ONLN dø9 ÃE “ )l4 ° d ONLN d¡9Ej )HPrint action vector ° d ONLN d’Q <]á (y ZGPrint action routine vector; set up at boot time. See M.TE.PrintAction. ° d ONLN d i `u ≠ +$ smSysScript ° d ONLN d )j Ãv “ )l2 ° d ONLN d +jvÅ )HPreferred system script ° d ONLN d Cv `Ç ¥ (ü ~ smLastScript ° d ONLN d Pw ÃÉ “ )l2 ° d ONLN d RwÉt )HLast keyboard script ° d ONLN d gÉ `è ≠ (¨ ~ smKeyScript ° d ONLN d sÑ Ãê “ )l2 ° d ONLN d uÑê` )HKeyboard script ◊ X◊
_KeyScript ° d ONLN dF ^ ^ j ´ )F routine. When ° d ONLN dV ] ´ i Ò )M
_KeyScript ° d ONLN d` ^ Ò j )F changes ° d ONLN di ] i\ ), KeyScript ° d ONLN dr ^\ jl )?, it ° d ONLN dw ^l j⁄ )moves the old value to ° d ONLN dé j v ^ ( ì 6
LastScript ° d ONLN dò k ^ w h )F. ° d ONLN dõ j h v Æ )
_KeyScript ° d ONLN d• k Æ wt )F+ can also swap the current key script with ° d ONLN d– kt w⁄ )Δthe last one, which it ° d ONLN dÁ x Ñ ] ( † 6retrieves from ° d ONLN dˆ w ] É £ )E
LastScript ° d ONLN dÛ ƒ • – ¬ )F, and ° d ONLN d˘ √ ¬ œ ) SysScript ° d ONLN d ƒ –« )?) always contain integers that correspond ° d ONLN d+ ƒ« –⁄ )Δto a ° d ONLN d0 – ‹ i ( ¯ 6script number. ° d ONLN d@ – i ‹Ω )Q?Script numbers are documented in The Script Manager chapter of ° d ONLN d –Ω ‹⁄ ( ¯€Inside ° d ONLN dÜ ‹ Ë I ( 6 Macintosh ° d ONLN dè ‹ I Ë ö )1, Volume V-293. ° d ONLN dü Ù < t ( ZsmSysRef ° d ONLN d® ı ® Æ )l2 ° d ONLN d™ ı 5 )HSystem folder ° d ONLN d∏ Ù5 t )E volRefNum ° d ONLN d¬ u (6 6Set from the global ° d ONLN d÷
u ¥ )] BootDrive ° d ONLN dfl ¥h )?' at boot time and switch-launch time. ° d ONLN d
hí )¥SysRef ° d ONLN d í⁄ )* was originally ° d ONLN d ' ˇ (C 62a way of testing for vanilla launch versus switch ° d ONLN dN ˇ'P )Álaunch; now the ° d ONLN d^P&Å )QEnabled ° d ONLN deÅ'⁄ )1 global is used for ° d ONLN dy' 3 V (O 6
that purpose. ° d ONLN dá? <K Ç +$
smKeyCache ° d ONLN dí@ ®L Æ )l2 ° d ONLN dî@ LY )H[Obsolete, do not use] ° d ONLN d´X <d { (Å Z smKeySwap ° d ONLN dµY ®e Æ )l4 ° d ONLN d∑Y eù )H!Keyboard swapping resource handle ° d ONLN dŸr ~ . (ö 6The ° d ONLN d›q .} X )'KSWP' ° d ONLN d„r X~ ∑ )* resource handle is ° d ONLN d˜r ∑~∞ )_1put here at boot time and switch-launch time. A ° d ONLN d(q∞}⁄ )˘'KSWP' ° d ONLN d/ ãÉ (ß 6Jresource contains a table of key sequences that will cause the currently ° d ONLN dyÉã∞ (ß°
installed ° d ONLN dÉ~∞ä⁄ )-'KCHR' ° d ONLN däå ò … (¥ 6#(keyboard mapping table) to change ° d ONLN d≠å …ò@ )±to the preferred system ° d ONLN d≈ã@ój )w'KCHR' ° d ONLN dÀåjò⁄ )*, switch to the Roman ° d ONLN d·ò § B (¡ 6'KCHR' ° d ONLN dÁô B• ” )* , or rotate among the available ° d ONLN dò ”§ ˝ )ë'KCHR' ° d ONLN d
ô ˝•⁄ )*/ resources. The table includes the virtual key ° d ONLN d=¶ ≤ ƒ (Œ 6!code and the modifier keys. The ° d ONLN d^¶ ƒ≤ )¨following is the ° d ONLN do•±D )V'KSWP' ° d ONLN du¶D≤⁄ )* resource for the Kanji script ° d ONLN dî≤ æ h (⁄ 6interface system.
° d ONLN d¶ ’ Æ * resource 'KSWP' (0, sysheap) { ° d ONLN dΔ‘ <fl ¥ +$
5Roman, 66, controlOff, optionOff, shiftOff, commandOn ° d ONLN d∞ <% A (A Z} ° d ONLN d≤$ / " (K 6};
° d ONLN dµ; G ë *The resource says rotate ° d ONLN dŒ: ëF ª )y'KCHR' ° d ONLN d‘; ªG )* resources if a ° d ONLN d‰;G⁄ )I'Space–Command key occurs, switch to the ° d ONLN d H T = (p 6system ° d ONLN dG =S g )%'KCHR' ° d ONLN dH gTe )*0 on keypad plus (+)–Command key, and switch to ° d ONLN dIHeTü )˛
the Roman ° d ONLN dSGüS… ):'KCHR' ° d ONLN dYH…T⁄ )* on ° d ONLN d]T ` ¡ (| 6 keypad asterisk (*)–Command key. ° d ONLN d~l <x Ç +$
smGenFlags ° d ONLN dâm ®y Æ )l4 ° d ONLN dãm y/ )H
General flags ° d ONLN dôÖ ëÇ (≠ 6OOnly the two high-order bits are defined (in the file ScriptEqu.a), as follows: ◊ 4◊˘
. +Z-Developer Support Center ( -Û June 1989 / X / ,
Courier
° d ONLN d ) ` 5 – ( R ~smfShowIcon = 31 ° d ONLN d * 6ß )¢#(show icon even if only one script) ° d ONLN d 5 6 ` B ◊ ( _ ~smfDualCaret = 30 ° d ONLN d G 7 Cª )¢)(use dual caret for mixed direction text) ° d ONLN d q P < \ R ( x ZThe ° d ONLN d u P R \ ± )high-order byte of ° d ONLN d à O ± [ )_ smgrGenFlags ° d ONLN d î P \˛ )T2, containing these flags, should be setup from the ° d ONLN d « \ < h _ ( Ö Zflags ° d ONLN d à ] _ i b )# ° d ONLN d Õ ] b i ô ) byte in the ° d ONLN d Ÿ \ ô h √ )7'itlc' ° d ONLN d fl ] √ i˛ )*C resource. This is not presently done, but will be fixed in future ° d ONLN d# i < u — ( ë Z versions of the Script Manager. ° d ONLN dC Ç < éT *4The following MPW Pascal procedure demonstrates how ° d ONLN dw ÇT éî ( ™rto get script ° d ONLN dÖ Åî çæ )@'SICN' ° d ONLN dã Çæ é˛ )*
resources to ° d ONLN dô é < öA ( ∂ Z:display even if there is only one script system installed.
° d ONLN d‘ ¶ < ± ñ *PROCEDURE SetSICN; ° d ONLN dÁ ∞ < ª K *
VAR ° d ONLN dÏ ∫ ` ≈ ø +$
SICNstate: Longint; ° d ONLN d ƒ ` œ ó *
err: Oserr; ° d ONLN d ÿ < „ U ( ˇ ZBEGIN ° d ONLN d ‚ ` Ì +$
BSET(SICNstate,smfShowIcon); ° d ONLN d] ` - *)err := SetEnvirons(smGenFlags,SICNstate); ° d ONLN dá
< P (1 ZEND;
° d ONLN då `, ¶ +$
smOverride ° d ONLN dó! Ã- “ )l4 ° d ONLN dô!-t )HScript override flags ° d ONLN dØ9 <E J (a ZAt ° d ONLN d≤9 JE˛ )\present, this is not set or used by the Script Manager. It is, however, reserved for future ° d ONLN dE <Q É (m Z
improvements. ° d ONLN d ] `i ª +$
smCharPortion ° d ONLN d+^ Ãj “ )l2 ° d ONLN d-^j… )H%Ch vs Sp Extra proportion, 4.12 fixed ° d ONLN dSv <Ç „ (û Z$This is 16-bit fixed-point value in ° d ONLN dwv „Dz )ß94.12 format (e.g., 10% = $0199). It is initialized to 10 ° d ONLN d±Ç <éÜ (™ ZCpercent at boot time. It is intended to be used by script systems ° d ONLN dÙÇÜé˛ (™§to allocate space among ° d ONLN d é <ös (∂ ZBintercharacter spacing and interword spacing when justifying text. ° d ONLN dO¶ <≤ ù *A 16-bit fixed-point ° d ONLN dd¶ ù≤˛ )aIvalue in 4.12 format is similar to the fixed-point number type defined on ° d ONLN dÆ≤ <æ y (⁄ Z
page I-79 of ° d ONLN dª≤ yæ ◊ )=Inside Macintosh . ° d ONLN dœ≤ ◊æ∂ )^1The obvious difference being that it is only 16 ° d ONLN d ≤∂æ˛ )flbits long. The ° d ONLN dæ < (Ê Z`integer part of the value is stored in the high four bits, and the fractional part is stored in ° d ONLN dpæ ˛ (Êthe ° d ONLN dt <÷ u (Ú Z low 12 bits. † Ç
y â ° d ONLN dˇˇ ( z128 † ó † ç † å † å ° ñ ° ö ˇ¸
ôü ° d ONLN dˇˇ (ö1 † ó
Z( "ó † ç ° ñ ° ö ˇ˝
ï • ° d ONLN dˇˇ ( ñ256 † ó † ç † å ° ñ ° ö ˇ¸
Ø!√ ° d ONLN dˇˇ +512 † ó ° ñ ° ö ˇ˝
≤Ω ° d ONLN dˇˇ (µ1 † ó
Z( "¥ † ç † å † å ° ñ ° ö ˇ˝
“ÿ ° d ONLN dˇˇ ) 1 † ó
Z( "– † ç ° ñ ° ö ˇ¸
!· ° d ONLN dˇˇ ( À1024 † ó † ç † å † å ° ñ ° ö ˇ¸
ÓÙ ° d ONLN dˇˇ (Ô1 † ó
Z( "Ï † ç ° ñ ° ö ˇ˝
Ê"¸ ° d ONLN dˇˇ ( Á2048 † ó † ç † å † å ° ñ ° ö ˇ˝
° d ONLN dˇˇ (
1 † ó
Z( " † ç ° ñ ° ö ˇ¸
! ° d ONLN dˇˇ ( 4096 † ó † ç ° ñ ° ö ˇ¸
Å á ° d ONLN dˇˇ ( Ç4 † ó † É
IR
° d ONLN dÅ •!ï +A%(16-bit Fixed-Point Number in 4.12 format
° d ONLN d™9 <H • (d ZLocal Variables
° d ONLN d∫T <` £ *Every script interface ° d ONLN d—T £`w )g+system has local variables. Page V-132 of ° d ONLN d¸Tw`Õ )‘Inside Macintosh ° d ONLN d
TÕ`˛ )V lists verbs ° d ONLN d` <l™ (à ZOwhich are constants that indicate which variable you want to read or set. The ° d ONLN dh`™l˛ (à»table of constants ° d ONLN d{l <x U (î Zused ° d ONLN dÄl Ux˛ )Zto access the local variable, although more accurate than the global table, does contain a ° d ONLN d€x <Ñ ° († Zfew inaccuracies. In ° d ONLN dÒx °Ñ˛ )eGaddition four new constants have been added. Table 2 gives the correct ° d ONLN d9Ñ <ê l (¨ Z
° d ONLN d ) < 5 n +$$Constant ° d ONLN d ) ∫ 5 ⁄ )~Value ° d ONLN d ) 5 )6Meaning T X T® ,
Courier ° d ONLN d 6 < B • ( _ ZsmScriptVersion ° d ONLN d ' 7 √ C … )á0 ° d ONLN d ) 7 CÖ )- Script Interface version number ° d ONLN d I C < O û ( l ZsmScriptMunged ° d ONLN d X D √ P … )á2 ° d ONLN d Z D Pe )-Local modification count ° d ONLN d s P < \ • ( y ZsmScriptEnabled ° d ONLN d É Q √ ] … )á4 ° d ONLN d Ö Q ]M )-Script Enabled Flag ° d ONLN d ô ] < i ó ( Ü Z
smScriptFlags ° d ONLN dÀ Δ √ “ œ )á22 ° d ONLN dŒ Δ “f )-Script Flags Word (new) ° d ONLN dÊ “ < fi ó ( ˚ Z
smScriptToken ° d ONLN dÙ ” √ fl œ )á24 ° d ONLN d˜ “ fi )-'itl4' ° d ONLN d˝ ” flo )* ID number (new) ° d ONLN d fl < Î ê ( Z smScriptRsvd ° d ONLN d ‡ √ Ï œ )á26 ° d ONLN d ‡ Ï )-Reserved ° d ONLN d' Ï < ¯ ê ( Z smScriptLang ° d ONLN d4 Ì √ ˘ œ )á28 ° d ONLN d7 Ì ˘z )- Script’s language code (new) ° d ONLN dT ˘ < • (" ZsmScriptNumDate ° d ONLN dd ˙ √ œ )á30 ° d ONLN dg ˙ G )- Number/date ° d ONLN ds ˙Gâ )Wrepresentation ° d ONLN dÇ < W (. Zcodes ° d ONLN dä +¥ (new) ° d ONLN dê <* ê (G Z smScriptKeys ° d ONLN dù √+ œ )á32 ° d ONLN d† + )-Script ° d ONLN dß *9 ) 'KCHR' ° d ONLN d≠ 9+H )* ID ° d ONLN d±+ <7 ê (T Z smScriptIcon ° d ONLN dæ, √8 œ )á34 ° d ONLN d¡, 8 )-Script ° d ONLN d»+79 ) 'SICN' ° d ONLN dŒ,98H )* ID ° d ONLN d“D <P ó (m Z
• (' ZsmScriptVersion ° d ONLN drˇ √ … )á4 ° d ONLN dtˇ ó )? Script Interface version number ° d ONLN dî # (? 6OWhen the script interface is loaded, this is set to the current version number. ° d ONLN d‰/ <; û +$smScriptMunged ° d ONLN dÛ0 √< … )á2 ° d ONLN dı0<w )?Local modification count ° d ONLN dI U Œ (q 6'This variable is incremented each time ° d ONLN d5H ŒT )∂
_SetScript ° d ONLN d?IUA )F is called. ° d ONLN dKa <m • (ä ZsmScriptEnabled ° d ONLN d[b √n … )á1 ° d ONLN d]bn_ )?Script Enabled Flag ° d ONLN dq{ á $ (£ 6A ° d ONLN dsz $Ü U ) Boolean ° d ONLN dz{ Uáó )1B which indicates whether the script has been enabled. Set to $FF ° d ONLN dº{óá⁄ (£µ when enabled ° d ONLN d…á ì ö (Ø 6and zero when not enabled. ° d ONLN d‰ü <´ ó +$
smScriptRight ° d ONLN dÚ† √¨ … )á1 ° d ONLN dÙ†¨V )?Right to Left Flag ◊ 4◊˘
. +Z-Developer Support Center ( -Û June 1989 / X /
° d ONLN d * < 6 G ( R ZA ,
Courier ° d ONLN d ) G 5 x ) Boolean ° d ONLN d * x 6S )12 indicating if text should be drawn right to left ° d ONLN d ; *S 6˛ )€'or left to right. It is set to $FF for ° d ONLN d c 6 < B± ( ^ ZRright to left text (Arabic and Hebrew scripts) and zero for left to right (Roman). ° d ONLN d ∂ N ` Z ¥ +$ smScriptJust ° d ONLN d √ O Á [ Ì )á1 ° d ONLN d ≈ O& [w )?Justification Flag ° d ONLN d ÿ g < s Ó ( è Z%A byte flag which describes how text ° d ONLN d ˝ g Ó s˛ )≤9should be justified. The possible settings correspond to ° d ONLN d7 s < ı ( õ Z)the justification flags used by TextEdit. ° d ONLN db ã ` ó f +$0 ° d ONLN dd ã Ñ ó ◊ )$= left justification ° d ONLN dz ó ` £ f ( ø ~1 ° d ONLN d| ó Ñ £ ” )$= center justified ° d ONLN dê £ ` Ø j ( À ~-1 ° d ONLN dì £ Ñ Ø Õ )$= right justified ° d ONLN d• ª ` « ¬ ( ‰ ~smScriptRedraw ° d ONLN d¥ º Á » Ì )á1 ° d ONLN d∂ º& »Å )?Word Redraw Flag ° d ONLN d« ‘ < ‡fl ( ¸ ZWA byte flag describing how much of a line should be redrawn when text is being entered. ° d ONLN d Ï ` ¯ f +$0 ° d ONLN d" Ï Ñ ¯ Î )$Only draw a character ° d ONLN d9 ¯ ` f ( ~1 ° d ONLN d; ¯ Ñ Û )$Redraw the entire word ° d ONLN dS ` j (, ~-1 ° d ONLN dV Ñ )$ Redraw the entire line (Arabic) ° d ONLN dv `( … (E ~smScriptSysFond ° d ONLN dÜ Á) Ì )á2 ° d ONLN dà &)ë )?Preferred System Font ° d ONLN dû5 <A Í (] Z This is the font family ID for ° d ONLN dΩ5 ÍA˛ )Æ.the preferred System Font. In a Roman system, ° d ONLN dÏA <M ó (j Z
ScriptSysFond ° d ONLN d˘B óN/ )[! is 0, the family ID for Chicago. ° d ONLN dZ `f … (É ~smScriptAppFond ° d ONLN d+[ Ág Ì )á2 ° d ONLN d-[&g§ )?Preferred Application Font ° d ONLN dHt <Ä ’ (ú Z!Font family ID for the preferred ° d ONLN dit ’Äó )ô&Application Font. In a Roman system, ° d ONLN dèsóÚ )¬
displayed. ° d ONLN d `* û +$ smScriptSort ° d ONLN d) Á* Ì )á4 ° d ONLN d+ &*k )?Script 'itl2' ID ° d ONLN d<7 <C z (_ Z Resource ID ° d ONLN dH7 zC ö )>of the ° d ONLN dO6 öB ƒ ) 'itl2' ° d ONLN dU7 ƒC+ )* for this script. The ° d ONLN dl6+BU )g'itl2' ° d ONLN dr7UC˛ )*$ contains routines for sorting. See ° d ONLN dóC <O ± (k ZM.TE.NewStringComp. ° d ONLN d´[ `g ª +$
° d ONLN d ¨ ) Ω +îBit ° d ONLN d ) . 5 ` ( Q LConstant ° d ONLN d
) ü 5 Ã )qNumber ° d ONLN d ) 51 )Q Description T J T‚ ,
Courier ° d ONLN d 6 . B Ç ( _ L smsfIntellCP ° d ONLN d - 7 ± C ∑ )É0 ° d ONLN d / 7 Cé )?$script has intelligent cut and paste ° d ONLN d T C . O Ç ( l L smsfSingByte ° d ONLN d a D ± P ∑ )É1 ° d ONLN d c D Pp )? script has only single bytes ° d ONLN d Ä P . \ { ( y L smsfNatCase ° d ONLN d å Q ± ] ∑ )É2 ° d ONLN d é Q ]æ )?+native characters have upper and lower case ° d ONLN d ∫ ] . i { ( Ü L smsfContext ° d ONLN d Δ ^ ± j ∑ )É3 ° d ONLN d » ^ jî )?#contextual script (e.g., AIS-based) ° d ONLN d Ï j . v ó ( ì LsmsfNoForceFont ° d ONLN d ¸ k ± w ∑ )É4 ° d ONLN d ˛ k wa )?will not force characters ° d ONLN d w . É Ç ( † L smsfB0Digits ° d ONLN d% x ± Ñ ∑ )É5 ° d ONLN d' x Ñ )? has alternative digits in B0-B9 ° d ONLN dG Ñ . ê m ( ≠ L smsfForms ° d ONLN dQ Ö ± ë Ω )É13 ° d ONLN dT Ö ëá )?!uses contextual forms for letters ° d ONLN dv ë . ù â ( ∫ L
smsfLigatures ° d ONLN dÑ í ± û Ω )É14 ° d ONLN dá í ûc )?uses contextual ligatures ° d ONLN d° û . ™ { ( « L smsfReverse ° d ONLN d≠ ü ± ´ Ω )É15 ° d ONLN d∞ ü ´z )? reverses native text, right-left J ‚ ° d ONLN d— ∏ ° ƒP ( ‡ ø Table 3–Constant Bit Numbers ° d ONLN dÓ – < ‹ Ñ ( ¯ Z
smScriptToken ° d ONLN d¸ – √ ‹ … )á2 ° d ONLN d˛ – ‹G )?Script 'itl2' ID ° d ONLN d È ı c ( 6Resource ID of ° d ONLN d È c ı u )Kthe ° d ONLN d" Ë u Ù ü )'itl4' ° d ONLN d( È ü ı )* for this script. The ° d ONLN d? Ë Ù0 )g'itl4' ° d ONLN dE È0 ı⁄ )*# contains contains tables needed by ° d ONLN di ˆ ( 66the number formatting and conversion routines and the ° d ONLN dü ı x ( ;
intRoman = 2; ° d ONLN d¢ N )êcalArabicLunar = 2; ° d ONLN d∂ `# ¨ (? ~intJapanese = 3; ° d ONLN d» #= )êcalJapanese = 3; ° d ONLN dŸ# `/ Ø (K ~intEuropean = 4; ° d ONLN dÎ# /4 )êcalJewish = 4; ° d ONLN d˛/ ;2 * calCoptic = 5; ° d ONLN d
G <S (o Z smScriptKeys ° d ONLN dG √S … )á4 ° d ONLN d GSZ )?Script 'KCHR' ID ° d ONLN d-_ kh (á 6BResource ID of preferred 'KCHR' resource. The 'KCHR' resource is ° d ONLN do_hk⁄ (áÜused to map virtual key ° d ONLN dák wC (ì 6<codes into the correct character code. See M.TB.KeyMapping. ° d ONLN dƒÉ <è { +$ smScriptIcon ° d ONLN d—É √è … )á4 ° d ONLN d”ÉèT )?Script 'SICN' ID ◊ 4◊˘
. +Z-Developer Support Center ( -Û June 1989 / X /
° d ONLN d < ) † ( E ZResource ID of the ° d ONLN d † )˛ )dEsmall icon that is used to represent which country specific resources ° d ONLN d Y * < 6 @ ( R Z( ,
Courier ° d ONLN d Z ) @ 5 j )'itl0' ° d ONLN d ` * j 6 q )*, ° d ONLN d b ) q 5 õ )'itl1' ° d ONLN d h * õ 6 ¢ )*, ° d ONLN d j ) ¢ 5 Ã )'itl2' ° d ONLN d p * Ã 6 ” )*, ° d ONLN d r ) ” 5 ˝ )'KCHR' ° d ONLN d x * ˝ 6˛ )*8) are currently installed in the system. Presently, the ° d ONLN d ± 7 < C Ö ( _ Z
Roman system ° d ONLN d æ 7 Ö C Í )Idoes not display the ° d ONLN d ” 6 Í B )e'SICN' ° d ONLN d Ÿ 7 C˛ )*/. Arabic, Kanji, Chinese, and Hebrew interface ° d ONLN d C < Oà ( k ZGsystems do display this icon in the upper-right corner of the menu bar. ° d ONLN dQ [ ` g ª +$
smScriptPrint ° d ONLN d_ \ Á h Ì )á4 ° d ONLN da \& hß )? Script printer action routine ° d ONLN dÄ t < Ät ( ú Z<Print action routine vector; setup when script is installed ° d ONLN dº tt IJ ( úíby Script Manager. See ° d ONLN d‘ Ä < å ñ ( ® ZM.TE.PrintAction. ° d ONLN dÊ ò ` § ¥ +$ smScriptTrap ° d ONLN dÛ ô Á • Ì )á4 ° d ONLN dı ô& •{ )?Trap entry pointer ° d ONLN d ± < Ω ( Ÿ Z,Pointer to Script dispatch routine. Script ° d ONLN d4 ± Ω˛ )“,Manager routines always belong to one of two ° d ONLN da Ω < …Ÿ (  ZRgroups. The first group of routines are common to every script interface system, ° d ONLN d≥ ΩŸ …˛ ( ˜and the ° d ONLN dª … < ’ ( Ò Z,second group must be supplied by the script ° d ONLN dÁ … ’˛ )€0interface system. This variable will point to a ° d ONLN d ÷ < ‚z ( ˛ ZEdispatch routine for the interface-supplied routines. When you call ° d ONLN d] ’z ·« ( ˛ò _ScriptUtil ° d ONLN dh ÷« ‚Œ )M, ° d ONLN dj ÷Œ ‚˛ ) it looks at ° d ONLN dv ‚ < Ó (
Z/the selector that is passed and either calls a ° d ONLN d• ‚ Ó˛ )À1common routine or calls the routine whose address ° d ONLN d◊ Ô < ˚ y ( Z
is stored in ° d ONLN d‰ Ó y ˙ ø )=
ScriptTrap ° d ONLN dÓ Ô ø ˚ )F. The routine in ° d ONLN d Ó ˙l )Y smScriptTrap ° d ONLN d Ôl ˚° )T will then ° d ONLN d Ô° ˚˛ )5use the selector to ° d ONLN d+ ˚ <™ (# ZRvector to the correct routine. In general, routines that display or measure text ° d ONLN d} ˚™˛ (#»in some way will ° d ONLN dé < ¡ (/ Z be supplied by the interface. ° d ONLN d¨ <+ X *A list ° d ONLN d≥ X+˛ ) Vat the end of this Note indicates which routines are implemented by the Script Manager ° d ONLN d
+ <7Y (S Z=and which routines are supplied by a script interface system. ° d ONLN dHC `O … +$smScriptCreator ° d ONLN dXD ÁP Ì )á4 ° d ONLN dZD&Pw )?Script file creator ° d ONLN dn\ <h Ê (Ñ Z$The four character creator type for ° d ONLN dí\ Êh˛ )™9the script interface’s file. For Roman it is “ZSYS,” the ° d ONLN dÃh <t  (ê Z$same creator as any system file has. ° d ONLN dÒÄ `å ¥ +$ smScriptFile ° d ONLN d˛Å Áç Ì )á4 ° d ONLN d Å&çp )?Script file name ° d ONLN dô <• › (¡ Z!A pointer to the a Pascal string ° d ONLN d2ô ›•˛ )°9which contains the name of the file containing the script ° d ONLN dl• <±0 (Õ Z3interface system. For the Roman SIS, it is System. ° d ONLN d†Ω `… ¥ +$ smScriptName ° d ONLN d≠æ Á Û )á44 ° d ONLN d∞æ& ^ )? Script name ° d ONLN dº÷ <‚+ (˛ Z0A pointer to a Pascal string which contains the ° d ONLN dÏ÷+‚˛ )Ô)script interface’s name. For Roman it is ° d ONLN d‚ <Ó ú (
Znaturally, “Roman.”
° d ONLN d* < ≠ *'Who Does What?
° d ONLN d9! <- ÷ * Table 4 breaks the documented ° d ONLN dW! ÷-˛ )ö:routines into common Script Manager routines and interface ° d ONLN dí- <9 ç (U Zspecific routines. ◊ X◊
° d ONLN d ) ` 5 » +H$Common Routines ° d ONLN d ) 5X )êInterface Supplied T | TÑ ,
Courier ° d ONLN d # 6 ` B ≠ ( _ ~ _FontScript ° d ONLN d / 6 B/ )ê _CharByte ° d ONLN d 9 B ` N ≠ ( k ~ _IntlScript ° d ONLN d E B N/ )ê _CharType ° d ONLN d O N ` Z ¶ ( w ~
_KeyScript ° d ONLN d Z N Z= )ê _Pixel2Char ° d ONLN d f Z ` f ¥ ( É ~ _GetEnvirons ° d ONLN d s Z f= )ê _Char2Pixel ° d ONLN d f ` r ¥ ( è ~ _SetEnvirons ° d ONLN d å f rR )ê_Transliterate ° d ONLN d õ r ` ~ ¥ ( õ ~ _Font2Script ° d ONLN d ® r ~/ )ê _FindWord ° d ONLN d ≤ ~ ` ä ≠ ( ß ~ _Format2Str ° d ONLN d æ ~ ä= )ê _HiliteText ° d ONLN d ä ` ñ ¥ ( ≥ ~ _FormatStr2X ° d ONLN d ◊ ä ñ/ )ê _DrawJust ° d ONLN d · ñ ` ¢ ≠ ( ø ~ _FormaX2Str ° d ONLN d Ì ñ ¢D )ê _MeasureJust ° d ONLN d ˙ ¢ ` Æ … ( À ~_GetFormatOrder ° d ONLN d
¢ Æ= )ê _ParseTable ° d ONLN d Æ ` ∫ ¬ ( ◊ ~_InitDateCache ° d ONLN d% Æ ∫R )ê_VisibleLength ° d ONLN d4 ∫ ` Δ ª ( „ ~
_IntlTokenize ° d ONLN dB ∫ ΔR )ê_FindScriptRun ° d ONLN dQ Δ ` “ ¬ ( Ô ~_LongDate2Secs ° d ONLN d` Δ “D )ê _PortionText ° d ONLN dm “ ` fi ¬ ( ˚ ~_LongSecs2Date ° d ONLN d| fi ` Í ≠ * _Str2Format ° d ONLN dà Í ` ˆ ¥ * _String2Date ° d ONLN dï ˆ ` ¥ * _String2Time ° d ONLN d¢ ` – * _StyledLineBreak ° d ONLN d≥ ` ≠ * _ToggleDate ° d ONLN dø `& g * E |EÑ ° d ONLN d¡3 ??≤ ([ ]?Table 4–Script Manager Routines and Interface Specific Routines ° d ONLN dW c ^ (Ä 6
_GetScript ° d ONLN d X ^d { )F and ° d ONLN dW {c ¡ )
_SetScript ° d ONLN dX ¡dH )F, which return the values ° d ONLN d4XHd⁄ )á of local script variables, are ° d ONLN dSd pœ (å 6\implemented by the Script Manager for some verbs and the script interface system for others. ° d ONLN d∞} âN *AThere is also a group of Script Manager routines which don’t use ° d ONLN dÒ}Nâ` (•lthe ° d ONLN dı|`à≠ ) _ScriptUtil ° d ONLN d }≠â⁄ )M
trap, but ° d ONLN d â ï t (± 6are documented in ° d ONLN d â tï )\ The Script Manager chapter of ° d ONLN d;âïc )úInside Macintosh ° d ONLN dKâcï⁄ )S, Volume V-293 or The ° d ONLN daï ° Ô (Ω 6+Script Manager 2.0 Interim Chapter. There ° d ONLN dåï Ô°÷ )◊1routines are utilities that read and write to low ° d ONLN dΩï÷°⁄ )Á- ° d ONLN dæ° ≠K (… 6<memory or PRAM. It is important to use these routines when ° d ONLN d˙°K≠⁄ (…i they are available. That will ° d ONLN d≠ πS (’ 6Callow Apple to modify where global variables, etc. are stored, and ° d ONLN d\≠Sπ⁄ (’q your application will remain ° d ONLN dyπ ≈ † (· 6 compatible. The utilities are: ° d ONLN dö— <› û +$GetDefFontSize ° d ONLN d™› <È Ç *
GetSysFont ° d ONLN d∂È <ı Ç *
GetAppFont ° d ONLN d¬ı < ó *
GetMBarHeight ° d ONLN d— <
Ç *
GetSysJust ° d ONLN d›
< Ç *
SetSysJust ° d ONLN dÈ <% ó *
ReadLocation ° d ONLN dˆ ó&1 )[ (documented in Interim Chapter) ° d ONLN d& <2 û (O ZWriteLocation ° d ONLN d%' û38 )b (documented in Interim Chapter) ° d ONLN dEW c Ç ( 6Further Reference: Ç 4Ǣ ° d ONLN dXd *p . +
• ° d ONLN dZd <p ç )Inside Macintosh ° d ONLN djd çp> )Q", Volume V-293, The Script Manager ° d ONLN dçp *| . (ò H• ° d ONLN dèp <| õ )M.TB.KeyMapping ° d ONLN dü| *à . (§ H• ° d ONLN d°| <à í )M.TE.PrintAction ◊ 4◊˘
ONLN f ˛ † å ° d 1drw2 … -·_ Ä ˇˇˇˇˇˇ è ° ñ x ° d drw2 : ° d drw2 : $ ° d 4drw2 : ° ö ˇ˙ ó@ † ò , Times
. R… R… +]BNew Technical Notes † ô ° d drw2 : °„ † ó ° d 1drw2 eÙ Ä ˇˇˇˇˇˇ P ° ñ x ° d drw2 : ° d drw2 : $ ° d 4drw2 : ° ö ˇ˚Ä E¿ † ò
( {ïDeveloper Support † ô ° d drw2 : °„ † ó ° d `drw2 - Ô ˇˇˇˇˇˇ K Ô - Z f f Z ° d 1drw2 ¿˙È ˇˇˇˇˇˇ K ° ñ x ° d drw2 : ° d drw2 : $ ° d 4drw2 : 0 ° ö ˇÙ Ä † ò
0 ( UÔ † ô ° d drw2 : °„ † ó ° d 1drw2 ÔÊ˙ ˇˇˇˇˇˇ ° ñ x ° d drw2 : ° d drw2 : $ ° d 4drw2 : ° ö ˇ˝Ä † ò
+& ® † ô ° d drw2 : °„ † ó ° d 1drw2  -¯ y ˇˇˇˇˇˇ ° ñ x ° d drw2 : ° d drw2 : $ ° d 4drw2 : ° ö ˇ˚Ä % † ò
( Z \ Macintosh † ô ° d drw2 : °„ † ó † ç ° d drw2 D † É
IR . ° d ONLN d z < çü ( ß Z(Modifying the Standard String Comparison
° d ONLN d ) å < õ Z *Text ° d ONLN d / åg õ˛ ( ∑ÖM.TE.NewStringComp
° d ONLN d B ß < ≥ t ( œ Z Revised by: ° d ONLN d O ß≈ ≥˛ ( œ„
March 1988 ° d ONLN d Z ≥ < ø q ( € Z Written by: ° d ONLN d f ≥ Ñ ø ª )H
Mark Davis ° d ONLN d s ø Ñ À Ï * Priscilla Oppenheimer ° d ONLN d â ø± À˛ ( Áœ
November 1987 ° d ONLN d ó ◊ < „K ( ˇ Z9This technical note describes how to modify the standard ° d ONLN d – ◊K „˛ ( ˇi$string comparison by constructing an ,
Courier ° d ONLN d ı „ < Ô X ( Zitl2 ° d ONLN d ˘ ‰ X \ ) ° d ONLN d ˙ ‰ \ ˛ )Qresource. Developers may want to modify the standard string comparison if Apple’s ° d ONLN dL < ¸ê ( ZIcomparison doesn’t meet their needs or if Apple has not written a string ° d ONLN dï ê ¸˛ (Æcomparison routine for ° d ONLN d¨ ¸ < ÷ ($ Z the language that concerns them. 3 X3
° d ONLN dÕ- << ≥ *4General Structure
° d ONLN dflI <U Q *The ° d ONLN d„H QT m )itl2 ° d ONLN dÁI mU ≈ ) resource contains ° d ONLN d˙I ≈U˛ )X?a number of procedures that are used for accurate comparison of ° d ONLN d:U <aE (} Z6text by the International Utilities Package. Refer to ° d ONLN dpUEaö (}cInside Macintosh ° d ONLN dÄUöa˛ )U, volume V for an ° d ONLN díb <n (ä Z/explanation of the algorithm used. The default ° d ONLN d¡am4 )‹itl2 ° d ONLN d≈b4n˛ ) ) for standard English text, which does no ° d ONLN dÔn <z (ñ Z+special processing, has the following form:
° d ONLN d Ü `ë +$ ; normal Include/Load statements ° d ONLN d>ê `õ *
&Include 'hd:mpw:aincludes:ScriptEqu.a' ° d ONLN dfö `• y *
Intl1 ° d ONLN dJ‡ ÑÎ ò )HProc ° d ONLN dPÍ `ı t ( ~With ° d ONLN dUÍ Ñı Ì )$IUSortFrame,IUStrData ° d ONLN dkÙ <ˇ x ( Z HookDispatch ° d ONLN dy˛ ` t +$
*'(Modifying the Standard String Comparison (Ï1 ) of 8 ˇ ° ¿Ù%%DSIDICT:_cv
currentdict /bu known {bu}if
userdict /_cv known not{userdict /_cv 30 dict put}if
_cv begin
/bdf{bind def}bind def
currentscreen/cs exch def/ca exch def/cf exch def
/setcmykcolor where{/setcmykcolor get /cvcmyk exch def}{/cvcmyk{1 sub 4 1 roll 3{3 index add neg dup 0 lt{pop 0}if 3 1 roll}repeat setrgbcolor pop}bdf }ifelse
/ss{//cf //ca //cs setscreen}bdf
/stg{ss setgray}bdf
/strgb{ss setrgbcolor}bdf
/stcmyk{ss cvcmyk}bdf
/min1{dup 0 eq{pop 1}if}bdf
end
currentdict /bn known {bn}if
† ø ◊# ˇ ˇˇˇˇ # ◊
IR , Times
. +6-Macintosh Technical Notes / 4 /˘ ,
Courier
° d ONLN d < ( _ +$EndWith ° d ONLN d ' < 2 _ *
EndWith ° d ONLN d 1 < < K *
End
° d ONLN d G Só ( o 6PIf modifications need to be made to the comparison process, then one or more of ° d ONLN d f Gó S⁄ ( oµthe dispatches ° d ONLN d u S _ Ô ( { 60will be modified to point to different routines:
° d ONLN d` £ Ø ( À 64There are a number of different changes that can be ° d ONLN dî £ Ø⁄ )Ù(made to the comparison routines. Some of ° d ONLN dΩ Ø ª Ω ( ◊ 6!the common modifications include: ° d ONLN dfl « ” . * 1. ° d ONLN d‰ « < ” )$$Comparing two bytes as one character ° d ONLN d
” < fl * 'Yugoslavian “l” < “lj” < “m”; Japanese… ° d ONLN d2 ” fly )ÿ[InitProc, FetchProc] ° d ONLN dH fl Î . ( 6 2. ° d ONLN dM fl < Î ˆ )$'Comparing characters in different order ° d ONLN dv Î < ˜ ü * Norwegian “z” < “å” ° d ONLN dç Î ˜S )ÿ
[ProjectProc] ° d ONLN dõ ˜ . ( 6 3. ° d ONLN d† ˜ < ‘ )$ Comparing one character as two ° d ONLN d¿ < ï * German “ä” ≈ “ae” ° d ONLN d’S )ÿ
[ProjectProc] ° d ONLN d„ . (7 6 4. ° d ONLN dË << )$7Ignoring characters unless strings are otherwise equal: ° d ONLN d! <' * )“blackbird” < “black-bird” < “blackbirds” ° d ONLN dK'S )ÿ
[ProjectProc] ° d ONLN dY' 3 . (O 6 5. ° d ONLN d^' <3 Ÿ )$ Changing the secondary ordering ° d ONLN d3 <? ≠ * Bibliographic “a” < “A” ° d ONLN dô3?U )ÿ
[VernierProc] ° d ONLN dßK W≠ (s 6OThe comparison hook procedures are all assembly language based, with arguments ° d ONLN dˆK≠W⁄ (sÀ described ° d ONLN d W c Ô ( 6-below. Since the routines may be called once ° d ONLN d-W Ôc⁄ )◊2per character in both strings, the routines should ° d ONLN d`c o (ã 6be as fast as possible. ° d ONLN dx{ á Ä *The condition codes ° d ONLN då{ Äá⁄ )hDare used to return information about the status of the hook routine. ° d ONLN d—à îb (∞ 6ETypically the normal processing of characters will be skipped if the ° d ONLN dábìw (∞ÄCCR ° d ONLN dàwî• ) is set to ° d ONLN d$á•ì≥ ).NE ° d ONLN d&à≥î⁄ ), so the ° d ONLN d/ï ° ∫ (Ω 6"default return should always have ° d ONLN dQî ∫† » )¢EQ ° d ONLN dSï »° fl ) set. ° d ONLN dYï fl°⁄ )4Each of these routines has access to the stack frame ° d ONLN dé° ≠ 4 ( 6(A6) ° d ONLN dí¢ 4Æ^ ) > used in the comparison routine, which has the following form:
° d ONLN d—∫ ≈ O (· 6 IUSortFrame ° d ONLN d›∫ `≈ ~ )HRecord ° d ONLN d‰∫ Ñ≈ Ÿ )${oldA6},Decrement ° d ONLN dˆƒ œ 6 (Î 6result ° d ONLN d˝ƒ <œ P )$ds.w ° d ONLN dƒ `œ e )$1 ° d ONLN dŒ Ÿ 6 (ı 6argTop ° d ONLN d Œ <Ÿ K )$equ ° d ONLN dŒ `Ÿ e )$* ° d ONLN dÿ „ @ (ˇ 6aStrText ° d ONLN dÿ `„ t )Hds.l ° d ONLN d ÿ Ñ„ â )$1 ° d ONLN d!‚ Ì @ ( 6bStrText ° d ONLN d*‚ `Ì t )Hds.l ° d ONLN d/‚ ÑÌ â )$1 ° d ONLN d1Ï ˜ ; ( 6aStrLen ° d ONLN d9Ï `˜ t )Hds.w ° d ONLN d>Ï Ñ˜ â )$1 ° d ONLN d@ˆ ; ( 6bStrLen ° d ONLN dHˆ ` t )Hds.w ° d ONLN dMˆ Ñ â )$1 ° d ONLN dO ; (' 6argSize ° d ONLN dW ` o )Hequ ° d ONLN d[ Ñ ¨ )$argTop-* ° d ONLN dd
6 (1 6return ° d ONLN dk
< P )$ds.l ° d ONLN dp
` e )$1 ° d ONLN dr 1 (; 6oldA6 ° d ONLN dy ` t )Hds.l ° d ONLN d~ Ñ â )$1 ° d ONLN dÄ ) 1 (E 6aInfo ° d ONLN dá `) j )Hds ° d ONLN dä Ñ) ± )$ IUStrData ° d ONLN dî( 3 1 (O 6bInfo ° d ONLN dõ( `3 j )Hds ° d ONLN dû( Ñ3 ± )$ IUStrData ° d ONLN d®2 = @ (Y 6wantMag ° d ONLN d±2 `= t )Hds.b ° d ONLN d∂2 Ñ= â )$1 ° d ONLN d∏2 ®=/ )$ 1-MagStrig 0-MagIdString. ° d ONLN d‘< G 6 (c 6weakEq ° d ONLN d€< <G P )$ds.b ° d ONLN d‡< `G e )$1 ° d ONLN d„< ®GC )H ; Signals at most weak equality ° d ONLN dF Q 6 (m 6msLock ° d ONLN d
F <Q P )$ds.b ° d ONLN dF `Q e )$1 ° d ONLN dF ®Q* )H; high byte of master ptr. ° d ONLN d-P [ @ (w 6weakMag ° d ONLN d6P `[ t )Hds.b ° d ONLN d;P Ñ[ â )$1 ° d ONLN d=P ®[/ )$ -1 weak, 1 strong compare ° d ONLN dYZ e J (Å 6
supStorage ° d ONLN ddZ `e t )Hds.b ° d ONLN diZ Ñe é )$18 ° d ONLN dlZ ®e ¯ )$; extra storage. ° d ONLN d}d o E (ã 6 localSize ° d ONLN dád `o o )Hequ ° d ONLN dãd Ño â )$* ° d ONLN dçd ®o È )$
; frame size. ° d ONLN dùn `y t (ï ~EndR
° d ONLN d¢Ñ ê 8 (¨ 6There ° d ONLN d®Ñ 8ê⁄ ) Uare three fields in this frame that are of interest for altering text comparison. The ° d ONLN d˛ê ú ^ (π 6
(Ï 62 ) of 8 (ÏK(Modifying the Standard String Comparison ˇ ◊# ˇ ˇˇˇˇ # ◊
IR , Times
. +Z-Developer Support Center ( -Ï
March 1988 / X /
° d ONLN d < ) ” ( E Z two compared strings A and B, ° d ONLN d ” )˛ )ó?and information about the status of current characters in those ° d ONLN d ^ * < 6 s ( R Z string. The ,
Courier ° d ONLN d j ) s 5 ≤ )7 IUStrData ° d ONLN d s * ≤ 6E )? record has the following form:
° d ONLN d4 Ê < Ú∫ *RThe Init Procedure is used to initialize the comparison process. The main use for ° d ONLN dÜ Ê∫ Ú˛ (ÿthis procedure ° d ONLN dï Ú < ˛ π ( Z is for double-byte scripts. ° d ONLN d± Ú π ˛˛ )}GAs an optimization, the International Utilities will perform an initial ° d ONLN d˘ ˛ <
Ü (& ZFcheck on the two strings, comparing for simple byte-to-byte equality. ° d ONLN d? ˛Ü
˛ (&§Thus any common initial ° d ONLN dW
<„ (2 Z\substrings are checked before the Init procedure is called. The string pointers and lengths ° d ONLN d≥
„˛ (2in the ° d ONLN d∫ <" { (? Z IUStrData ° d ONLN d√ {#¡ )?D records have been updated to point just past the common substrings. ° d ONLN d/ <;c (W Z5Languages such as Japanese or Yugoslavian, which may ° d ONLN d=/c;˛ (WÅ consider two bytes to be one ° d ONLN dZ; <GQ (c Z8character, may have to back up one byte, as shown below.
; Routine ° d ONLN dÁ] Ñh ¨ )HInitProc ° d ONLN dg <r _ (é Z; Input ° d ONLN d¯g Ñr ˜ )HA6 Local Frame ° d ONLN dq <| d (ò Z; Output ° d ONLN dq Ñ|É )H3CCR NE to skip entire sort (usually set EQ) ° d ONLN dM{ <Ü i (¢ Z ; Trashes ° d ONLN dW{ ÑÜ )HStandard regs: ° d ONLN df{ Ü' )l A0/A1/D0-D2 ° d ONLN drÖ <ê n (¨ Z
; A length ° d ONLN d≈÷ `· y (˝ ~sub.w ° d ONLN dÀ÷ Ñ· „ )$AInfo.StrCnt(a6),d0 ° d ONLN dfl÷ ·T )l; see if its changed ° d ONLN dı‡ `Î y ( ~beq.s ° d ONLN d˚‡ ÑÎ ù )$@FixB ° d ONLN d‡ ÎJ )l; A is done if not ° d ONLN dÍ `ı y ( ~sub.l ° d ONLN d Í Ñı ù )$#2,sp ° d ONLN d%Í ı6 )l; return param ° d ONLN d5Ù `ˇ ~ ( ~move.l ° d ONLN d<Ù Ñˇ fi )$AStrText(a6),-(sp) ° d ONLN dOÙ ˇ )l ; textBuf ° d ONLN dZ˛ ` ~ (% ~move.w ° d ONLN da˛ Ñ ¨ )$d0,-(sp) ° d ONLN dk˛ , )l ; textOffset ° d ONLN dy ` ç (/ ~ _CharByte ° d ONLN dÑ ` y *
tst.w ° d ONLN dä Ñ ù )$(sp)+ ° d ONLN dí h )l; on character boundary? ° d ONLN d¨ `' y (C ~ble.s ° d ONLN d≤ Ñ' ù )$@FixB ° d ONLN d∫ '; )l; yes, continue ° d ONLN dÀ& `1 y (M ~sub.l ° d ONLN d—& Ñ1 „ )$#1,AInfo.StrPtr(A6) ° d ONLN dÂ& 1@ )l; adjust pointer ° d ONLN d˜0 `; y (W ~add.w ° d ONLN d˝0 Ñ; „ )$#1,AInfo.StrCnt(A6) ° d ONLN d0 ;6 )l; adjust count ° d ONLN d : <E U (a Z@FixB ° d ONLN d'D `O ~ +$
move.w ° d ONLN d.D ÑO œ )$BStrLen(a6), d0 ° d ONLN d>D O" )l
; B length ° d ONLN dJN `Y y (u ~sub.w ° d ONLN dPN ÑY „ )$BInfo.StrCnt(a6),d0 ° d ONLN ddN YT )l; see if its changed ° d ONLN dzX `c y ( ~beq.s ° d ONLN dÄX Ñc ± )$ Quit Init ° d ONLN dãX cJ )l; B is done if not ° d ONLN düb `m y (â ~sub.l ° d ONLN d•b Ñm ù )$#2,sp ° d ONLN d≠b m6 )l; return param ° d ONLN dΩl `w ~ (ì ~move.l ° d ONLN dƒl Ñw „ )$BStrText(a6), -(sp) ° d ONLN dÿl w )l ; textBuf ° d ONLN d„v `Å ~ (ù ~move.w ° d ONLN dÍv ÑÅ ± )$ d0, -(sp) ° d ONLN dıv Å, )l ; textOffset ° d ONLN d Ä `ã ç (ß ~ _CharByte ° d ONLN d ä `ï y *
(Ï Z(Modifying the Standard String Comparison (Ï3 ) of 8 ˇV ◊# ˇ ˇˇˇˇ # ◊
IR , Times
. +6-Macintosh Technical Notes / 4 /˘ ,
Courier
° d ONLN d < ( U +$add.w ° d ONLN d ` ( ø )$#1,BInfo.StrCnt(A6) ° d ONLN d à ( )l; adjust count ° d ONLN d ) ' 2 E ( N 6 @QuitInit ° d ONLN d 4 1 < < U +$
bra.s ° d ONLN d : 1 ` < à )$ReturnEQ ° d ONLN d D 1 Ã <? )l; return to the caller. ° d ONLN d ] ; < F _ ( b ZEndWith
° d ONLN d e ] l £ ( à 6The Fetch Procedure
° d ONLN d y x Ñ œ *'The Fetch Procedure is used to fetch a ° d ONLN d † x œ Ñ⁄ )∑8character from a string, updating the pointer and length ° d ONLN d Ÿ Ñ ê û ( ¨ 6 to reflect the remainder of ° d ONLN d ı Ñ û ê⁄ )Ü=the string. For example, the following code changes the text ° d ONLN d3 ê ú ° ( ∏ 6comparison for Yugoslavian:
° d ONLN dO ® ¥Œ *I;------------------------------------------------------------------------ ° d ONLN dô ≥ ø N * ; Routine ° d ONLN d£ ≥ ` ø ñ )H FetchProc ° d ONLN d≠ æ B ( Ê 6; Input ° d ONLN dµ æ ` & )H!A2 String Data Structure ° d ONLN d◊ … ’ ( Ò 6; ° d ONLN d⁄ … ` ’å )H2A3 String pointer (one past fetched char) ° d ONLN d
‘ ‡ $ ( ¸ 6; ° d ONLN d ‘ ` ‡ Í )HA6 Local Frame ° d ONLN d) fl Î ( 6; ° d ONLN d, fl ` λ )H<D4.W Character: top byte is fetched character, bottom ° d ONLN di Í ˆ ¸ ( 6&; is zero ° d ONLN dê ı * ; ° d ONLN dì ı `n )H-D5.B 1 if string is empty, otherwise 0 ° d ONLN d¡ H (( 6; Output ° d ONLN d ` ¬ )H;D4.W Character: top byte set to character, bottom to ° d ONLN d (3 6; ° d ONLN d ` fi )H extension ° d ONLN d " (> 6; ° d ONLN d" `"n )H-D5.B 1 if string is empty, otherwise 0 ° d ONLN dP! - N (I 6 ; Trashes ° d ONLN dZ! `- ¥ )HStandard regs: ° d ONLN di! Ã- )l A0/A1/D0-D2 ° d ONLN du, 8 T (T 6
; Function ° d ONLN dÄ, `8∂ )H9This routine returns the characters that are fetched from ° d ONLN d∫7 C (_ 6; ° d ONLN dΩ7 `C» )H<the string, if they are not just a sequence of single bytes. ° d ONLN d˙B NŒ (j 6I;------------------------------------------------------------------------
° d ONLN dDY d E * FetchProc ° d ONLN dOc <n U +$
tst.b ° d ONLN dUc `n j )$d5 ° d ONLN dZc ÃnX )l ; more characters in string? ° d ONLN dxm <x U (î Zbne.s ° d ONLN d~m `x à )$ReturnEq ° d ONLN dàm Ãx! )l; no -> bail out. ° d ONLN dõÅ <å Z (® Zmove.w ° d ONLN d¢Å `å y )$d4,d0 ° d ONLN d™Å Ãå! )l; load high byte. ° d ONLN dΩã <ñ Z (≤ Zmove.b ° d ONLN dƒã `ñ É )$(a3),d0 ° d ONLN dÕã Ãñ )l; load low byte. ° d ONLN d·ü <™ K (Δ Zlea ° d ONLN dÂü `™ ú )$ pairTable,a1 ° d ONLN dÛü Ù0 )l; load table address ° d ONLN d≥ æ T (⁄ 6 @compareChar ° d ONLN dΩ <» Z +$
move.w ° d ONLN d Ω `» à )$(a1)+,d1 ° d ONLN d'Ω Ã» )l ; pair = 0? ° d ONLN d4« <“ U (Ó Zbeq.s ° d ONLN d:« `“ à )$ReturnEq ° d ONLN dD« Ó: )l; yes -> end of table. ° d ONLN d\— <‹ U (¯ Zcmp.w ° d ONLN db— `‹ y )$d0,d1 ° d ONLN dj— Ë? )l; legal character pair? ° d ONLN dÉ€ <Ê U ( Zbne.s ° d ONLN d†`Ê ú )$ @compareChar ° d ONLN dó€ ÃÊI )l; no -> try the next one. ° d ONLN d≤ < U ( Zadd.w ° d ONLN d∏ ` y )$#1,a3 ° d ONLN d¿Â Ã0 )l; increment pointer. ° d ONLN d÷Ô <˙ U ( Zsub.w ° d ONLN d‹Ô `˙ ° )$
#1,StrCnt(a2) ° d ONLN dÎÔ Ã˙+ )l; decrement length. ° d ONLN d ˘ < Z ( Zaddx.w ° d ONLN d˘ ` y )$d5,d5 ° d ONLN d˘ ÃD )l; empty -> set the flag. ° d ONLN d) < Z (* Zmove.w ° d ONLN d0 ` y )$d0,d4 ° d ONLN d8 Ã: )l; copy character pair. ° d ONLN dP
< K (4 Zrts ° d ONLN dW
Ãb )ê ; return to caller with CCR=NE ° d ONLN dv! , E (H 6 pairTable ° d ONLN dÅ+ <6 P +$
dc.b ° d ONLN dÜ+ `6 t )$'Lj' ° d ONLN dç+ Ã6 ‡ )l; Lj ° d ONLN dì5 <@ P (\ Zdc.b ° d ONLN dò5 `@ t )$'LJ' ° d ONLN dü5 Ã@ ‡ )l; LJ ° d ONLN d•? <J P (f Zdc.b ° d ONLN d™? `J y )$'lJ' ° d ONLN d≤? ÃJ ‡ )l; lJ ° d ONLN d∏I <T P (p Zdc.b ° d ONLN dΩI `T t )$'lj' ° d ONLN dƒI ÃT ‡ )l; lj ° d ONLN dÃ] <h P (Ñ Zdc.b ° d ONLN d—] `h t )$'Nj' ° d ONLN dÿ] Ãh ‡ )l; Nj ° d ONLN dfig <r P (é Zdc.b ° d ONLN d„g `r t )$'NJ' ° d ONLN dÍg Ãr ‡ )l; NJ ° d ONLN dq <| P (ò Zdc.b ° d ONLN dıq `| t )$'nJ' ° d ONLN d¸q Ã| ‡ )l; nJ ° d ONLN d{ <Ü P (¢ Zdc.b ° d ONLN d{ `Ü t )$'nj' ° d ONLN d{ ÃÜ ‡ )l; nj ◊ 4◊˘
(Ï 64 ) of 8 (ÏK(Modifying the Standard String Comparison ˇ⁄ ◊# ˇ ˇˇˇˇ # ◊
IR , Times
. +Z-Developer Support Center ( -Ï
March 1988 / X / ,
Courier
° d ONLN d ' ` 2 t ( N ~dc.b ° d ONLN d ' Ñ 2 ¨ )$'D', $be ° d ONLN d ' 2 )l; Dz-hat ° d ONLN d 1 ` < t ( X ~dc.b ° d ONLN d 1 Ñ < ¨ )$'D', $ae ° d ONLN d ( 1 < )l; DZ-hat ° d ONLN d 2 ; ` F t ( b ~dc.b ° d ONLN d 7 ; Ñ F ¨ )$'d', $ae ° d ONLN d A ; F )l; dZ-hat ° d ONLN d K E ` P t ( l ~dc.b ° d ONLN d P E Ñ P ¨ )$'d', $be ° d ONLN d Z E P )l; dz-hat ° d ONLN d d Y ` d t ( Ä ~DC.B ° d ONLN d i Y Ñ d ¨ )$$00, $00 ° d ONLN d s Y d' )l ; table end ° d ONLN d o < z i ( ñ Z FetchProc ° d ONLN d ä y ` Ñ t +$
with ° d ONLN d ê y ® Ñ ’ )H IUStrData ° d ONLN d õ É ` é y ( ™ ~tst.b ° d ONLN d ¢ É ® é ≤ )Hd5 ° d ONLN d ß É é_ )l; empty string? ° d ONLN d ∏ ç ` ò y ( ¥ ~bne.s ° d ONLN d ø ç ® ò – )HReturnEq ° d ONLN d … ç òx )l; exit if length = 0 ° d ONLN d ‡ ° < ¨@ ( » Z4; if we have a double-byte char, add the second byte ° d ONLN d ´ ` ∂ o +$
lea ° d ONLN d ´ ® ∂ Ó )HCurChar(a2),a0 ° d ONLN d* ´ ∂Z )l; pass pointer ° d ONLN d: µ ` ¿ ~ ( ‹ ~move.w ° d ONLN dB µ ® ¿ À )Hd4,(a0) ° d ONLN dK µ ¿n )l; set value at ptr ° d ONLN d_ ø ` y ( Ê ~clr.w ° d ONLN df ø ® ≤ )Hd0 ° d ONLN dk ø U )l
; pass length ° d ONLN dz ” ` fi y ( ˙ ~sub.l ° d ONLN dÅ ” ® fi ¡ )H#2,SP ° d ONLN dâ ” fii )l; allocate return ° d ONLN dú › ` Ë ~ ( ~move.l ° d ONLN d§ › ® Ë – )Ha0,-(sp) ° d ONLN dÆ › ËA )l ; pointer ° d ONLN dπ Á ` Ú ~ ( ~move.w ° d ONLN d¡ Á ® Ú – )Hd0,-(sp) ° d ONLN dÀ Á Ú< )l; offset ° d ONLN d’ Ò ` ¸ ç ( ~ _CharByte ° d ONLN d‡ ˚ ` y *
tst.w ° d ONLN dÊ ˚ Ñ ù )$(sp)+ ° d ONLN dÓ ˚ 1 )l
move.b ° d ONLN dÉ# Ñ. ¨ )$(a3),d0 ° d ONLN dé#._ )ê; get next byte ° d ONLN dü- `8 y (T ~cmp.b ° d ONLN d•- Ñ8 ß )$#$DE,d0 ° d ONLN dØ-8A )ê ; nigori? ° d ONLN d∫7 `B y (^ ~beq.s ° d ONLN d¿7 ÑB ª )$ @DoubleByte ° d ONLN dŒ7B< )ê; add in ° d ONLN dÿA `L y (h ~cmp.b ° d ONLN dfiA ÑL ß )$#$DF,d0 ° d ONLN dËAL7 )ê; maru? ° d ONLN dÒK `V y (r ~bne.s ° d ONLN d˜K ÑV ¨ )$ReturnEq ° d ONLN dKVs )ê; exit: single byte ° d ONLN d_ <j s (Ü Z @DoubleByte ° d ONLN d#i `t ~ +$
move.b ° d ONLN d*i Ñt ¨ )$(a3)+,d4 ° d ONLN d5it_ )ê; get next byte ° d ONLN dFs `~ ~ (ö ~subq.w ° d ONLN dMs Ñ~ ≈ )$
#1,StrCnt(A2) ° d ONLN d]s~s )ê; dec string length ° d ONLN dr} `à ~ (§ ~addx.w ° d ONLN dy} Ñà ù )$d5,d5 ° d ONLN dÇ}àõ )ê set x=1 if string len = 0 ° d ONLN düá `í o (Æ ~rts ° d ONLN dßáí™ )¥ ; return to caller with CCR=NE
° d ONLN d‹ƒ <–\ *;The Project Procedure is used to find the primary ordering ° d ONLN dƒ\–˛ (Ïz"for a character. This routine will ° d ONLN d:– <‹ Ö (¯ Zmap characters ° d ONLN dI– Ö‹˛ )IQthat differ only in the secondary ordering onto a single character, typically the ° d ONLN dõ‹ <Ë ( ZYunmodified, uppercase character. For example, the following changes the comparison order ° d ONLN dÙ‹Ë˛ (for ° d ONLN d¯Ë <ÙG ( Z8some Norwegian characters, so that they occur after ‘Z.’
Ñ ª )H ProjectProc ° d ONLN dë < _ (; Z; Input ° d ONLN dô Ñ ) )H!A2 String Data Structure ° d ONLN dª <) A (E Z; ° d ONLN dæ Ñ)∞ )H<D4.W Character (top byte is char, bottom is extension ° d ONLN d˚( <3 A (O Z; ° d ONLN d˛( Ñ3∞ )H< (the extension is zero unless set by FetchProc)) ° d ONLN d;2 <= d (Y Z; Output ° d ONLN dD2 Ñ= )H D4.W Projected Character ° d ONLN dd< <G A (c Z; ° d ONLN dg< ÑG= )H%CCR NE to skip normal Project ° d ONLN dçF <Q i (m Z ; Trashes ° d ONLN dóF ÑQ )HStandard regs: ° d ONLN d¶F Q' )l A0/A1/D0-D2 ° d ONLN d≤P <[ n (w Z
; Function ° d ONLN dΩP Ñ[´ )H;This routine projects the secondary characters onto primary ° d ONLN d˘Z <e “ (Å Z ; characters. ° d ONLN dd <o A *
lea ° d ONLN däå Ñó ¿ )$ ProjTable,A1 ° d ONLN dóå Ãó5 )H; load table address. ° d ONLN d≠ñ <° i (Ω Z @findChar ° d ONLN d∏† `´ ~ +$
move.l ° d ONLN dø† Ñ´ ¨ )$(a1)+,D0 ° d ONLN d…† ´' )l ; get entry ◊ X◊
(Ï Z(Modifying the Standard String Comparison (Ï5 ) of 8 ˇä ◊# ˇ ˇˇˇˇ # ◊
IR , Times
. +6-Macintosh Technical Notes / 4 /˘ ,
Courier
° d ONLN d < ( U +$cmp.w ° d ONLN d ` ( y )$d0,d4 ° d ONLN d à (+ )l; original ≥ entry? ° d ONLN d # ' < 2 U ( N Zbhi.s ° d ONLN d ) ' ` 2 ç )$ @findChar ° d ONLN d 4 ' à 2I )l; no, try the next entry. ° d ONLN d O 1 < < U ( X Zbne.s ° d ONLN d U 1 ` < à )$ReturnEq ° d ONLN d _ 1 à <] )l ; not equal, process normally ° d ONLN d } E P T ( l 6 @replaceChar ° d ONLN d ã O < Z P +$
swap ° d ONLN d ê O ` Z j )$d0 ° d ONLN d ï O Ã Z! )l; get replacement ° d ONLN d ® Y < d Z ( Ä Zmove.w ° d ONLN d Ø Y ` d y )$d0,d4 ° d ONLN d ∑ Y Ã dI )l; set new character word. ° d ONLN d — c n E ( ä 6 @doneChar ° d ONLN d ‹ m < x K +$
rts ° d ONLN d „ m à xX )ê ; CCR is NE to skip project. ° d ONLN d Å å E ( ® 6 ProjTable ° d ONLN d ã ñ *
° d ONLN d∏ (7 6/The Project procedure can also be used to undo ° d ONLN dÁ ⁄ )Ù)the effects of the normal projection. For ° d ONLN d '∫ (C 6Wexample, suppose that “œ” is not to be expanded into “oe”: in that case, a simple test ° d ONLN dh∫'⁄ (Cÿcan be ° d ONLN do( 4 ® (P 6 made against 'œ',0, returning ° d ONLN dç' ®3 ∂ )êNE ° d ONLN dè( ∂4† )4 if there is a match, so that the normal processing ° d ONLN d√(†4⁄ )Í is not done. ° d ONLN d–4 @¢ (\ 6RTo expand one character into two, the routine should return the first replacement ° d ONLN d"4¢@⁄ (\¿ character in ° d ONLN d/@ L 4 (i 6D4.W ° d ONLN d3A 4M √ ) , and modify two fields in the ° d ONLN dR@ √L )è IUStrData ° d ONLN d[AMÄ )? field. For example, given ° d ONLN dvAÄMï )~that ° d ONLN d{@ïL£ )A1 ° d ONLN d}A£M⁄ ) points to a ° d ONLN däM Yq (u 6Ftable entry of the form (primaryCharacter: Word; secondaryCharacters: ° d ONLN d–MqY⁄ (uèWord), the following ° d ONLN dÂY e u (Å 6code could be used:
° d ONLN d˙q <| A +$… ° d ONLN d˝{ <Ü Z *
move.w ° d ONLN d{ `Ü à )$(a1)+,d4 ° d ONLN d{ ÃÜq )l!; return first, primary character ° d ONLN d1Ö <ê Z (¨ Zmove.w ° d ONLN d8Ö `ê µ )$(a1)+,CurChar(A2) ° d ONLN dJÖ Ãê{ )l#; original => first, modified char. ° d ONLN doè <ö Z (∂ Zaddq.b ° d ONLN dvè `ö ∞ )$#1,JustAfter(A2) ° d ONLN dáè Ãö] )l ; set to one (otherwise zero) ° d ONLN d¶ô <§ Z (¿ Zmove.b ° d ONLN d≠ô `§ ∞ )$(a1),BufChar(A2) ° d ONLN dæô çl )l ; store second character (BYTE!) , Geneva ° d ONLN d‡£ <Ø D (à Z…
6/should sort after the corresponding unexpanded ° d ONLN d%‚Ó⁄ )ˆ%form. This field must be set whenever ° d ONLN dKÓ ˙ I ( 6CurChar ° d ONLN dRÔ I˚ )1, is modified in order for the comparison to ° d ONLN d~Ô ˚u )‘be fully ordered. ° d ONLN dêÓu˙¶ )XBufChar ° d ONLN dóÔ¶˚⁄ )1 stores the ° d ONLN d£¸ ‰ ($ 6-next byte to be retrieved from the string by ° d ONLN d–˚ ‰# )à FetchChar ° d ONLN dŸ¸#' )?. ° d ONLN d€ . (< 6;To handle the case where characters are ignored unless the ° d ONLN d. ⁄ (<L"two compared strings are otherwise ° d ONLN d9! - I (I 6 equal, the ° d ONLN dD I, z )1IgnChar ° d ONLN dK! z- )1 flag can be set. This can be ° d ONLN di! -⁄ )Ü,used to handle characters such as the hyphen ° d ONLN dñ- 9 ∞ (U 6 in English, or vowels in Arabic.
° d ONLN d∏E <P A +$… ° d ONLN dªO <Z U *
cmp.w ° d ONLN d¡O `Z í )$
#hyphen,d0 ° d ONLN dÕO ÃZ0 )l; is it a ignorable? ° d ONLN d„Y <d K (Ä Zseq ° d ONLN dÁY `d ó )$ IgnChar(a2) ° d ONLN dÙY Ãd0 )l; set whether or not ° d ONLN d
c <n A (ä Z… ◊ 4◊˘
(Ï 66 ) of 8 (ÏK(Modifying the Standard String Comparison ˇ2 ◊# ˇ ˇˇˇˇ # ◊
IR , Times
. +Z-Developer Support Center ( -Ï
March 1988 / X /
° d ONLN d ) < 8 ◊ ( T ZThe Vernier Procedure
° d ONLN d D < P• *JThe Vernier Procedure is used to make a final comparison among characters ° d ONLN d ` D• P˛ ( l√that have the same ° d ONLN d s Q < ] ( y Z+primary ordering. It is only needed if the ,
; Routine ° d ONLN d^ £ Ñ Æ ª )H VernierProc ° d ONLN dj ≠ < ∏ _ ( ‘ Z; Input ° d ONLN dr ≠ Ñ ∏ ¿ )H D4.B ° d ONLN dÄ ≠ ∏^ )lHigh byte of character ° d ONLN dó ∑ < ¬ A ( fi Z; ° d ONLN dö ∑ Ñ ¬ ª )H D5.B ° d ONLN d¶ ∑ Ã ¬: )H Low byte of character ° d ONLN dΩ ¡ < Ã d ( Ë Z; Output ° d ONLN dΔ ¡ Ñ Ã ª )H D4.B ° d ONLN d“ ¡ Ã Ã? )H High byte of character ° d ONLN dÍ À < ÷ A ( Ú Z; ° d ONLN dÌ À Ñ ÷ ª )H D5.B ° d ONLN d˘ À Ã ÷: )H Low byte of character ° d ONLN d ’ < ‡ A ( ¸ Z; ° d ONLN d ’ Ñ ‡ ª )H CCR ° d ONLN d ’ Ã ‡g )H NE if to skip standard Vernier ° d ONLN d? fl < Í i ( Z ; Trashes ° d ONLN dI fl Ñ Í )HStandard regs: ° d ONLN dX fl Í' )l A0/A1/D0-D2 ° d ONLN dd È < Ù n ( Z
not.b ° d ONLN ds% ®0 ≤ )Hd4 ° d ONLN dw% 0w )H invert secondary ordering ° d ONLN dî/ `: y (V ~not.b ° d ONLN dõ/ ®: ≤ )Hd5 ° d ONLN dü/ :^ )H; ditto for lower byte ° d ONLN d∑9 `D y (` ~bra.s ° d ONLN dæ9 ®D – )HReturnEq ° d ONLN d«9 DÜ )H ; normal processing afterwards
° d ONLN dÊ[ <j î (Ü ZInstalling an ° d ONLN dÙ\ îk ∏ )Xitl2 ° d ONLN d¯[ ∏j ˆ )$ resource
° d ONLN dw <É ~ (ü Z To write an ° d ONLN dv ~Ç ö )Bitl2 ° d ONLN dw öÉP ) $ resource, follow the guidelines in ° d ONLN d7wPɲ )∂ M.PT.StandAloneCode for writing ° d ONLN dWÉ <èfl (´ ZUstandalone code in MPW. The code should be written in assembly language, and it must ° d ONLN d¨Éflè˛ (´˝follow ° d ONLN d≥è <õK (∑ Z;the specifications given in this technical note or serious ° d ONLN dÓèKõ˛ (∑i"system errors could occur whenever ° d ONLN dõ <ß « (√ Z string comparisons are made. ° d ONLN d.¥ <¿ *)The default comparison routine is in the ° d ONLN dW≥ø )≈itl2 ° d ONLN d[¥ ¿÷ ) ' resource of the System file. In order ° d ONLN dÇ¥÷¿˛ )πto use a ° d ONLN dã¡ <Õ (È Z0comparison routine other than the standard one, ° d ONLN dª¡ Õè )‰you should include an ° d ONLN d—¿èô )oitl2 ° d ONLN d’¡´Õ˛ ) resource in your ° d ONLN dÁÕ <Ÿ (ı Z,application with the same name and resource ° d ONLN dÕŸ˛ )’1ID as the one in the System file that you wish to ° d ONLN dEŸ <° ( ZKchange. The Resource Manager will look for the resource in the application ° d ONLN dêŸ°Â˛ (øresource file before ° d ONLN d•Â <Ò • (
Zit looks in the System ° d ONLN dºÂ •Ò˛ )iHresource file, so your string comparison routine will be used instead of ° d ONLN dÒ <˝ Ö ( Zthe default one. ° d ONLN d <ê *GIt is generally a dangerous practice to change a system resource since ° d ONLN d] ê˛ (1Æother applications may ° d ONLN dt <" } (> Zdepend on it, ° d ONLN dÇ }"∂ )A>but if you have good reasons to permanently change the system ° d ONLN d¿∂!“ (>‘itl2 ° d ONLN dƒ“"˛ ) resource ° d ONLN dŒ" <.p (J ZBso that all applications use a different comparison routine, then ° d ONLN d "p.˛ (Jé you should write an installer ° d ONLN d ./ <; û (W Zscript to change the ° d ONLN d C. û: ∫ )bitl2 ° d ONLN d G/ ∫;\ ) ! resource in the System resource ° d ONLN d h/\;˛ )¢$file. Writing an installer script is ° d ONLN d ç; <G# (c Z/documented in M.TP.Installer. You are required ° d ONLN d º;#G˛ )Á0to write an installer script if you are planning ° d ONLN d ÌG <Si (o Z<to ship your application on a licensed system software disk ° d ONLN d
)GiS˛ (oá and your application makes a ° d ONLN d
FS <_/ ({ Z0permanent change to any resources in the System ° d ONLN d
vS/_˛ )Û)file. We strongly discourage changing the ° d ONLN d
†` <l d (à ZSystem ° d ONLN d
ß_ dk Ä )(itl2 ° d ONLN d
´` ÄlC ) & as that would change the behavior of ° d ONLN d
—`Cl˛ )√%string comparison and sorting for all ° d ONLN d
˜l <xÏ (î Z]applications. If that is your intent, then you should write an installer script. However, if ° d ONLN d TlÏx˛ (î
(Ï Z(Modifying the Standard String Comparison (Ï7 ) of 8 ˇ¯ ◊# ˇ ˇˇˇˇ # ◊
IR , Times
. +6-Macintosh Technical Notes / 4 /˘
° d ONLN d ) 5 Ç *$Further Reference: T 4 T˘ ° d ONLN d 6 * B . +
• ° d ONLN d 6 < B ¥ )The International Utilities ° d ONLN d 1 B * N . ( j H• ° d ONLN d 3 B < N Ç )M.TP.Installer ° d ONLN d B N * Z . ( v H• ° d ONLN d D N < Z ¨ )M.PT.StandAloneCode ◊ 4◊˘
(Ï 68 ) of 8 (ÏK(Modifying the Standard String Comparison ˇ| ◊# ˇ ˇˇˇˇ # ◊ † Ç
/ Z Å#
0Ià:µú9 " { ˇˇˇˇˇˇˇˇ # † ƒ ° d
ONLN f ˛ † å ° d 1drw2 … -·_ Ä ˇˇˇˇˇˇ è ° ñ x ° d drw2 : ° d drw2 : $ ° d 4drw2 : ° ö ˇ˙ ó@ † ò , Times
. R… R… +]BNew Technical Notes † ô ° d drw2 : °„ † ó ° d 1drw2 eÙ Ä ˇˇˇˇˇˇ P ° ñ x ° d drw2 : ° d drw2 : $ ° d 4drw2 : ° ö ˇ˚Ä E¿ † ò
( {ïDeveloper Support † ô ° d drw2 : °„ † ó ° d `drw2 - Ô ˇˇˇˇˇˇ K Ô - Z f f Z ° d 1drw2 ¿˙È ˇˇˇˇˇˇ K ° ñ x ° d drw2 : ° d drw2 : $ ° d 4drw2 : 0 ° ö ˇÙ Ä † ò
0 ( UÔ † ô ° d drw2 : °„ † ó ° d 1drw2 ÔÊ˙ ˇˇˇˇˇˇ ° ñ x ° d drw2 : ° d drw2 : $ ° d 4drw2 : ° ö ˇ˝Ä † ò
+& ® † ô ° d drw2 : °„ † ó ° d 1drw2  -¯ y ˇˇˇˇˇˇ ° ñ x ° d drw2 : ° d drw2 : $ ° d 4drw2 : ° ö ˇ˚Ä % † ò
( Z \ Macintosh † ô ° d drw2 : °„ † ó † ç ° d drw2 D † É
IR . ° d ONLN d z < çÄ ( ß Z%Styled TextEdit Changes in System 6.0
° d ONLN d & å < õ Z *Text ° d ONLN d , åc õ˛ ( ∑ÅM.TE.TextEditChanges
° d ONLN d A ß < ≥ t ( œ Z Revised by: ° d ONLN d M ß Ñ ≥ ≈ )H
Chris Derossi ° d ONLN d [ ߥ ≥˛ ( œ“
December 1988 ° d ONLN d i ≥ < ø q ( € Z Written by: ° d ONLN d u ≥ Ñ ø ≈ )H
Chris Derossi ° d ONLN d É ≥¡ ø˛ ( €fl August 1988 ° d ONLN d è À < ◊h ( Û Z<Some changes were made to TextEdit in System 6.0 to provide ° d ONLN d À Àh ◊˛ ( ÛÜ more functionality and to make ° d ONLN d Í ◊ < „ P ( ˇ Zlife ° d ONLN d Ô ◊ P „˛ )Peasier for the programmer using TextEdit. This Note documents those changes and ° d ONLN d@ „ < Ô Ç ( Z
enhancements. ° d ONLN dN < ¸ ë *
Changes since ° d ONLN d\ ë ¸ „ )U
August 1988: ° d ONLN di „ ¸T )R Corrected an error in ,
Courier ° d ONLN dÅ ÔT ˚Ø )q
TEDispatchRec ° d ONLN dé Ø ¸˛ )[ in the figure on ° d ONLN d† ¸ < _ ($ Zpage 8. 3 X3
° d ONLN d®- << ± *4TextEdit Changes
° d ONLN dπH <T › *"In order to improve the usability ° d ONLN d€H ›T˛ )°8of styled TextEdit, some routines have been changed, and ° d ONLN dT <`ˆ (| Z[some new routines have been added. These changes exist in System Software 6.0 and later. ° d ONLN doTˆ`˛ (|If ° d ONLN dr` <l (à Z+you intend to rely on any of these changes ° d ONLN dù`l˛ )‹.or new routines, it is important that you call ° d ONLN dÃl <x ê (ï Z _SysEnvirons ° d ONLN dÿm êy‡ )TG first to make sure you are running under System Software 6.0 or later. ° d ONLN d Ö <ë ê (Æ Z _SysEnvirons ° d ONLN d,Ü êí" )T is documented in ° d ONLN d>Ü"íÉ )íInside Macintosh ° d ONLN dNÜÉí˛ )a, Volume V and ° d ONLN d]í <û √ (∫ ZM.OV.GestaltSysenvirons. ° d ONLN dví √û˛ )á; To check for the styled TextEdit changes, you might do the ° d ONLN d≤û <™ m (Δ Z
following:
° d ONLN dæ∂ `¡ o +$VAR ° d ONLN dƒ¿ ÑÀ ± +$
theWorld: ° d ONLN dŒ¿ ÃÀ ˛ )H
SysEnvRec; ° d ONLN d€ Ñ’ ù (Ò ¢anErr ° d ONLN d· ®’ ≠ )$: ° d ONLN d„ Ã’ Í )$OSErr; ° d ONLN dÎfi `È y ( ~BEGIN ° d ONLN dÛË ÑÛ. +$
"anErr := SysEnvirons(1, theWorld); ° d ONLN dÚ Ñ˝ø *
?IF (anErr = noErr) AND (theWorld.systemVersion >= $0600) THEN … ° d ONLN d\¸ ® +$
{System 6.0 or later} ° d ONLN ds ` t (- ~END;
° d ONLN dx( <7 ˛ (S Z Changes to Existing Routines
saved in the ° d ONLN d.Pl\´ )A nullScrap ° d ONLN d7Q´]˛ )? to be applied to ° d ONLN dI] <i – (Ö Z subsequently typed characters. ° d ONLN dh] –i˛ )î= As soon as the user has backspaced past the beginning of the ° d ONLN d¶i <u{ (ë ZGstyle, or clicked in some other area of the text, the style is removed. ° d ONLN dÓÅ <ç ê * GetStylScrap ° d ONLN d˙Ç êéÛ )TD now returns a handle to a valid style scrap record when called for ° d ONLN d>ÇÛé˛ (™an ° d ONLN dAè <õ ã (∑ Zinsertion point ( ° d ONLN dRé ãö √ )OselStart ° d ONLN dZè √õ ‘ )8 = ° d ONLN d]é ‘ö ˛ )selEnd ° d ONLN dcè ˛õ )*). ° d ONLN dgéö% )NIL ° d ONLN djè%õ* ) ° d ONLN dkè*õú )is still returned when ° d ONLN dÇéúö )r GetStylScrap ° d ONLN déèõ˛ )T is ° d ONLN díú <® ´ (ƒ Zcalled with an old style ° d ONLN d´õ ´ß „ )oTEHandle ° d ONLN d≥ú „® Á )8. ◊ X◊
(Ï Z%Styled TextEdit Changes in System 6.0 (Ï1 ) of 7 ˇ ° ¿Ù%%DSIDICT:_cv
currentdict /bu known {bu}if
userdict /_cv known not{userdict /_cv 30 dict put}if
_cv begin
/bdf{bind def}bind def
currentscreen/cs exch def/ca exch def/cf exch def
/setcmykcolor where{/setcmykcolor get /cvcmyk exch def}{/cvcmyk{1 sub 4 1 roll 3{3 index add neg dup 0 lt{pop 0}if 3 1 roll}repeat setrgbcolor pop}bdf }ifelse
/ss{//cf //ca //cs setscreen}bdf
/stg{ss setgray}bdf
/strgb{ss setrgbcolor}bdf
/stcmyk{ss cvcmyk}bdf
/min1{dup 0 eq{pop 1}if}bdf
end
currentdict /bn known {bn}if
† ø" ◊# ˇ ˇˇˇˇ # ◊
IR , Times
. +6-Macintosh Technical Notes / 4 /˘ ,
Courier
° d ONLN d ) 5 ^ *%
TESetStyle ° d ONLN d
* ^ 6 )F! now accepts an additional mode, ° d ONLN d + ) 5< )¶doToggle ° d ONLN d 3 *< 6@ )8 ° d ONLN d 4 *@ 6D )( ° d ONLN d 5 )D 5b )= 32 ° d ONLN d 9 *b 6ï ) ). When ° d ONLN d B )ï 5Õ )3doToggle ° d ONLN d J *Õ 6⁄ )8 is ° d ONLN d N 7 C } ( _ 6specified along with ° d ONLN d c 6 } B ß )edoFace ° d ONLN d i 7 ß C Ø )*, ° d ONLN d k 6 Ø B ı )
TESetStyle ° d ONLN d u 7 ı Cæ )F, operates as follows: If a style specified ° d ONLN d ° 7æ C⁄ )…in the ° d ONLN d ® D P 7 ( l 6given ° d ONLN d Æ C 7 O v ) TextStyle ° d ONLN d ∑ D v Pp )?4 parameter exists across the entire selected range, ° d ONLN d Î Dp P⁄ )˙that style is removed ° d ONLN d P \ Y ( x 6(turned off). ° d ONLN d P Y \⁄ )ATOtherwise, all of the selected text is set to include that style. When a particular ° d ONLN de \ h ( Ñ 6cstyle is set for an entire selection range, that style is said to be continuous over the selection. ° d ONLN d… t ÄM *DFor example, given that the following text is the current selection: †09 † Ç
ˇˇ¸ˇˇÄ ć> Ù ˝ 0 0` Ù ˝ @ Ä Û †˝ Ä Ô Û ‡˝ Ä Ô Û @˝ ˛ Ô Û @˝ ˛ Ô ◊ ◊ ◊ ◊ Ù ˛ @P @Ä Ù ¸¸ @@ @Ô ı …ïÄ fS L¨ ı *V@ ITÄ R≤ ı )‘@ GT N¢ ı *T@ IT R¢ ı *T@ ITÄ R¢ ı …¥@ &” M¢
ı ¯ Ó
ı ¯ Ó † É
IR ° d ONLN dÒ§ ∞ Ç (Ã 6On the other hand, if ° d ONLN d£ ÇØ » )j
TESetStyle ° d ONLN d§ »∞h )F had been called with a mode of ° d ONLN d1£hØí )†doFace ° d ONLN d7§í∞ñ )* ° d ONLN d8§ñ∞¢ )+ ° d ONLN d:£¢Ø⁄ ) doToggle ° d ONLN dC± Ω 4 (Ÿ 6and a ° d ONLN dI∞ 4º s ) TextStyle ° d ONLN dR± sΩ v )? ° d ONLN dS∞ vº † )tsFace ° d ONLN dY± †Ω » )*
field of ° d ONLN dc∞ »º )([italic] ° d ONLN dk± Ωà )8+, then the selected text would have become: †09 † Ç
° d ONLN dÆf r ó *Some new routines ° d ONLN d¿f ór_ ) have been added to TextEdit, ° d ONLN d›e_q÷ )»TEContinuousStyle ° d ONLN dÓf÷r⁄ )w, ° d ONLN dr ~ fi (õ 6 SetStylScrap, TECustomHook, ° d ONLN d s fi Ô )Δand ° d ONLN dr Ô~D ) TENumStyles ° d ONLN dsDö )U. These routines ° d ONLN d-sö⁄ )V
are described ° d ONLN d; ã a (ß 6in detail below. ◊ 4◊˘
*E2 ) of 7 (ÏY%Styled TextEdit Changes in System 6.0 ˇ ◊# ˇ ˇˇˇˇ # ◊
IR , Times
. +Z-Developer Support Center ( -fi
December 1988 / X /
° d ONLN d ) ÷ 5c ( Q ÙAssembly language note: ° d ONLN d 6 Ñ B ( ^ ¢The new TextEdit routines ° d ONLN d 2 6 Bi )àare called via the ,
° d ONLN d Ì ø < À‡ *FFUNCTION TEContinuousStyle(VAR mode : Integer; VAR aStyle : TextStyle; ° d ONLN d9 ÷û +¥ hTE : TEHandle) : Boolean;
° d ONLN dW · < Ì ≥ (
ZTEContinuousStyle ° d ONLN dh ‚ ≥ Ó ‘ )w gives ° d ONLN do ‚ ‘ Ó˛ )!>you information about the attributes of the current selection. ° d ONLN dØ Ô < ˚ S ( ZThe ° d ONLN d≥ Ó S ˙ o )mode ° d ONLN d∑ Ô o ˚ t ) ° d ONLN d∏ Ô t ˚b )-parameter, which takes the same values as in ° d ONLN d Ób ˙® )Ó
TESetStyle ° d ONLN dÔ Ô® ˚˛ )F, specifies which ° d ONLN d ¸ < ˆ ($ Z$attributes should be checked. When ° d ONLN d% ˚ ˆm )∫TEContinuousStyle ° d ONLN d6 ¸mØ )w returns, the ° d ONLN dD ˚ØÀ )Bmode ° d ONLN dH ¸À– ) ° d ONLN dI ¸–˛ ) parameter ° d ONLN dS <r (0 Z=indicates which of the checked attributes is continuous over ° d ONLN dêr˛ (0êthe selection range and the ° d ONLN d¨ < f (= ZaStyle ° d ONLN d≤ f![ )*8 parameter is set to reflect the continuous attributes. ° d ONLN dÎ- <9 ≥ (V ZTEContinuousStyle ° d ONLN d¸. ≥: ⁄ )w returns ° d ONLN d- ⁄9 ˆ )'TRUE ° d ONLN d . ˆ:] ) if all of the attributes ° d ONLN d#.]:˛ )g to be checked are continuous and ° d ONLN dD: <F _ (c ZFALSE ° d ONLN dI; _G Ì )#! if not. In other words, if the ° d ONLN dj: ÌF )émode ° d ONLN dn; G“ ) , parameter is the same before and after the ° d ONLN dö;“G˛ )…
call, then ° d ONLN d•G <S ≥ (p ZTEContinuousStyle ° d ONLN d∂H ≥T ⁄ )w returns ° d ONLN døG ⁄S ˆ )'TRUE ° d ONLN d√H ˆT ˙ ) . ° d ONLN d≈a <m ~ (â Z
For example, ° d ONLN d“` ~l ı )BTEContinuousStyle ° d ONLN d„a ım¡ )w, is useful for marking the style menu items ° d ONLN da¡m˛ )Ã based on the ° d ONLN d m <y ç (ï Zcurrent selection.
° d ONLN d0Ö `ê ´ +$mode := doFace; ° d ONLN dAè `ö_ *
3IF TEContinuousStyle(mode, aStyle, myTE) THEN BEGIN ° d ONLN dvô `§x *
8{ There is at least one face that is continuous over the ° d ONLN d∞£ `ÆÇ *
: selection. Note that it might be plain which is actually ° d ONLN dÏ≠ `∏ ˆ *
aStyle.tsFace ° d ONLN d« â ÷ )[ field is a bit tricky. When ° d ONLN d … ’â )âTEContinuousStyle ° d ONLN dˆ â ÷æ )w returns a ° d ONLN d …æ ’⁄ )5mode ° d ONLN d ◊ „ X ( ˇ 6that contains ° d ONLN d ÷ X ‚ Ç )@doFace ° d ONLN d ◊ Ç „ Æ )* , and an ° d ONLN d# ÷ Æ ‚ ),
aStyle.tsFace ° d ONLN d0 ◊ „
)[ ° d ONLN d1 ◊
„i )field that contains ° d ONLN dE ÷i ‚À )\[bold, italic] ° d ONLN dS ◊À „⁄ )b, it ° d ONLN dX „ Ô≥ ( 6Zmeans that the selected text is all bold and all italic, but may contain other text faces ° d ONLN d≤ „≥ Ô⁄ ( —as well. ° d ONLN dº Ô ˚ ‚ ( 6-None of the other faces will apply to all of ° d ONLN dÈ Ô ‚ ˚⁄ ) 3the selected text, or they would have been included ° d ONLN d ¸ 5 ($ 6in the ° d ONLN d$ ˚ 5 _ ) tsFace ° d ONLN d* ¸ _ï )*I field. But if the tsFace field is the empty set ([] = plain), then all ° d ONLN ds ¸ï⁄ ($≥of the selected ° d ONLN dÉ R (0 6text is plain. ° d ONLN dí! - Ó */If the current selection range is an insertion ° d ONLN d¡! Ó- )÷point, ° d ONLN d» ,Ü )!TEContinuousStyle ° d ONLN dŸ!Ü-⁄ )w returns the style ° d ONLN dÏ. : w (V 6information for the ° d ONLN d . w: )_ next character to be typed. ° d ONLN d -9| )éTEContinuousStyle ° d ONLN d..|:⁄ )w will always return ° d ONLN dB: F 4 (c 6TRUE ° d ONLN dF; 4G ‘ ) % in this case, and each field of the ° d ONLN dk: ‘F )† TextStyle ° d ONLN dt;Gt )? record will be set if ° d ONLN dã;tG⁄ )athe corresponding bit ° d ONLN d°H T 5 (p 6in the ° d ONLN d®G 5S Q ) mode ° d ONLN d¨H QT ¨ ) parameter was set.
° d ONLN d¿l { k (ó 6 SetStylScrap
° d ONLN dŒá <ìÄ +$6PROCEDURE SetStylScrap(rangeStart, rangeEnd : LongInt; ° d ONLN d í ®û¬ +l / newStyles : StScrpHandle; hTE : TEHandle);
old style ° d ONLN dLœ C€ { )+TERecord ° d ONLN dT– {‹ Ç )8, ° d ONLN dVœ Ç€ ÷ ) SetStylScrap ° d ONLN db– ÷‹ )T does nothing. ° d ONLN dqË Ù l ( 6 SetStylScrap ° d ONLN d}È lı Û )T will terminate without error ° d ONLN dõÈ Ûı⁄ )á1if it prematurely reaches the end of the range or ° d ONLN dÕı ú ( 6Vif there are not enough scrap style elements to cover the whole range. In the latter ° d ONLN d#ıú⁄ ( ∫case, the last ° d ONLN d2
^ () 6Hstyle in the scrap record will be applied to the remainder of the range.
° d ONLN dflb n 0 (ä 6This ° d ONLN d‰b 0n ‚ )%function returns the number of style ° d ONLN d b ‚n )≤changes ° d ONLN dbn⁄ )&+ contained in the given range, counting one ° d ONLN d<n z ) (ñ 6for ° d ONLN d@n )z⁄ )[the start of the range. Note that this does not necessarily represent the number of unique ° d ONLN dúz ÜE (¢ 6@styles for the range, because some styles may be repeated. For ° d ONLN d‹zEÜ⁄ (¢c old-style TextEdit records, this ° d ONLN d˝Ü í î (Æ 6function always returns 1. ◊ 4◊˘
*>4 ) of 7 (ÏY%Styled TextEdit Changes in System 6.0 ˇ™ ◊# ˇ ˇˇˇˇ # ◊
IR , Times
. +Z-Developer Support Center ( -fi
December 1988 / X /
° d ONLN d < )˘ ( E ZXThis function is useful for calculating the amount of memory that would be required for ° d ONLN d X ˘ )˛ ( Ea ° d ONLN d Z * < 6 É ( R Zcontemplated _ ,
Courier ° d ONLN d h ) É 5 ¶ )GTECut ° d ONLN d m * ¶ 6 º )# or _ ° d ONLN d r ) º 5 Ê )TECopy ° d ONLN d x * Ê 6
)* . Since ° d ONLN d Å *
6˛ )'4the style scrap record is linear in nature, with one ° d ONLN d ∂ 7 < Cç ( _ ZDelement for each style change, you can multiply the result returned ° d ONLN d ˙ 7ç Cü ( _´by ° d ONLN d ˝ 6ü BÏ ) TENumStyles ° d ONLN d 7Ï C˛ )M by ° d ONLN d C < O œ ( l ZSizeOf(ScrpSTElement) ° d ONLN d! D œ PÍ )ì; and add 2 to get the amount of memory that will be needed.
° d ONLN d] h < w £ ( ì Z TECustomHook
° d ONLN dk É ` èº +$:PROCEDURE TECustomHook(which : TEHook; VAR addr : ProcPtr; ° d ONLN d™ é à öJ +l hTE : TEHandle);
° d ONLN d¿ • < ± à ( Õ ZThis procedure ° d ONLN dœ • à ±˛ )LMlets applications customize the functions of TextEdit by setting the TextEdit ° d ONLN d ≤ < æ ¥ ( ⁄ Zbottleneck routines. The ° d ONLN d7 ± ¥ Ω ◊ )xwhich ° d ONLN d< ≤ ◊ æˆ )#> parameter specifies which bottleneck routine to replace, and ° d ONLN dz ≤ˆ æ˛ ( ⁄is ° d ONLN d} ø < À d ( Á Zof type ° d ONLN dÖ æ d é )(TEHook ° d ONLN dã ø é À )* (described below). When ° d ONLN d• æ m )ã TECustomHook ° d ONLN d± øm ÀØ )T returns, the ° d ONLN dø æØ À )Baddr ° d ONLN d√ øÀ À– ) ° d ONLN dƒ ø– À˛ ) parameter ° d ONLN dŒ à < ÿ w ( Ù Z
contains the ° d ONLN d€ à w ÿÉ );8address of the previous bottleneck routine specified by ° d ONLN d ÀÉ ◊¶ ( Ù°which ° d ONLN d ö ÿ˛ )#. This is returned ° d ONLN d, ÿ < ‰ ( Z1so that bottleneck routines can be daisy-chained.
lineStarts ° d ONLN dÜ∂ ˘¬j )F array in the edit record. ° d ONLN d°œ <€, (˜ Z3None of these bottleneck routines are called from _ ° d ONLN d‘Œ,⁄] )TextBox ° d ONLN d€œ]€a )1.
° d ONLN d›Û < ë ( Z TEEOLHook
° d ONLN dÁ <≥ *SThis routine tests a given character and returns with the appropriate status flags ° d ONLN d:≥˛ (6—set in the status ° d ONLN dL <'{ (C ZFregister. The default action is to merely compare the character with ° d ONLN dí{&ê (Cô$0D ° d ONLN dïê'ì ) ° d ONLN dñì'˛ )(a carriage return) and ° d ONLN dÆ' <3 \ (O Zreturn. ° d ONLN d∂? <K h * On entry: ° d ONLN d¿? ÑK í )HD0 ° d ONLN d√? ®K )$character to compare ° d ONLN d⁄?\Kx )¥(byte) ° d ONLN d„K ÑW í (s ¢A3 ° d ONLN dÊK ®W2 )$ pointer to the TextEdit record ° d ONLN d K\Wy )¥(long) ° d ONLN d W Ñc í ( ¢A4 ° d ONLN d W ®c0 )$ handle to the TextEdit record ° d ONLN d 1W\cy )¥(long) ° d ONLN d 8o <{ a (ó ZOn exit: ° d ONLN d Bo ®{é )l4z flag clear if end-of-line character, set otherwise ◊ X◊
(Ï Z%Styled TextEdit Changes in System 6.0 (Ï5 ) of 7 ˇÇ ◊# ˇ ˇˇˇˇ # ◊
IR , Times
. +6-Macintosh Technical Notes / 4 /˘
° d ONLN d ) 8 v *' TEWidthHook
° d ONLN d D P 0 *This ° d ONLN d D 0 P⁄ )Yroutine is called any time the width of various components of a line are calculated. The ° d ONLN d k P \n ( x 6Lappropriate font, face, and size characteristics have already been set into ° d ONLN d ∑ Pn \⁄ ( xåthe current port by the ° d ONLN d œ ] i ( Ö 6=time this routine is called. The default action is to call _ ,
° d ONLN d& b *EThis routine is called any time the various components of a line are ° d ONLN dkb⁄ (*Ädrawn. The appropriate ° d ONLN dÉ ∞ (6 6Xfont, face, and size characteristics have already been set into the current port by the ° d ONLN d€∞⁄ (6Œ time this ° d ONLN d ' Û (C 63routine is called. The default action is to call _ ° d ONLN d Û&+ )€DrawText ° d ONLN d +'b )8 and return. ° d ONLN d-4 @ D (\ 6 On entry: ° d ONLN d73 `? n )HD0 ° d ONLN d:4 Ñ@ » )$offset into text ° d ONLN dM48@Y )¥(word) ° d ONLN dV@ `L n (i ~D1 ° d ONLN dYA ÑM È )$length of text to draw ° d ONLN drA8MY )¥(word) ° d ONLN d{M `Y n (v ~A0 ° d ONLN d~N ÑZ Ï )$pointer to text to draw ° d ONLN dóN8ZU )¥(long) ° d ONLN d†Z `f n (É ~A3 ° d ONLN d£[ Ñg )$ pointer to the TextEdit record ° d ONLN d√[8gU )¥(long) ° d ONLN dÃg `s n (ê ~A4 ° d ONLN dœh Ñt )$ handle to the TextEdit record ° d ONLN dÓh8tU )¥(long)
° d ONLN dıå õ ~ (∑ 6
TEHitTestHook
° d ONLN dß ≥- *>This routine is called to determine the character position in ° d ONLN dAß-≥⁄ (œK&a line given the horizontal offset, in ° d ONLN dh¥ ¿ U (‹ 6
pixels, from ° d ONLN du¥ U¿[ )=9the beginning of a line. The default action is to call _ ° d ONLN dÆ≥[ø° (‹y
Pixel2Char ° d ONLN d∏¥°¿⁄ )F and return. ° d ONLN dΔ¡ Õ ® (È 6 For more information, see the ° d ONLN d‰¡ ®Õ Ù )êdescription of _ ° d ONLN dÙ¿ ÙÃ: )L
Pixel2Char ° d ONLN d˛¡:Õ⁄ )F! in the Script Manager chapter of ° d ONLN d Õ Ÿ j (ı 6Inside Macintosh ° d ONLN d0Õ jŸ± )RB, Volume 5 and the Inside Macintosh Interim Chapter Draft, Script ° d ONLN drÕ±Ÿ⁄ (ıœManager ° d ONLN dzŸ  , ( 62.0. ° d ONLN dÚ ˛ D * On entry: ° d ONLN dâÒ `˝ n )HD0 ° d ONLN dåÚ Ñ˛ )$length of text to hit test ° d ONLN d®Ú8˛Y )¥(word) ° d ONLN d±˛ `
n (' ~D1 ° d ONLN d¥ˇ Ñ )$ pixel offset from start of text ° d ONLN d’ˇ8 Y )¥(word) ° d ONLN dfi ` n (4 ~A0 ° d ONLN d· Ñ È )$pointer to start of text ° d ONLN d¸ 8U )¥(long) ° d ONLN d `$ n (A ~A3 ° d ONLN d Ñ% )$ pointer to the TextEdit record ° d ONLN d(8%U )¥(long) ° d ONLN d1% `1 n (N ~A4 ° d ONLN d4& Ñ2 )$ handle to the TextEdit record ° d ONLN dS&82U )¥(long) ° d ONLN dZ? K = (g 6On exit: ° d ONLN dc> `J n )HD0 ° d ONLN df? ÑK ˆ )$pixel width to last offset ° d ONLN dÇ?8Kn )¥
(low word) ° d ONLN dêK ÑW (s ¢ Boolean = TRUE if a character ° d ONLN dÆK8Wq )¥ (high word) ° d ONLN dΩW Ñct ( ¢2offset corresponding to the pixel width was found. ° d ONLN dÚc `o n (å ~D1 ° d ONLN dıd Ñp à )$character offset ° d ONLN dd8pY )¥(word) ° d ONLN dp `| n (ô ~D2 ° d ONLN dq Ñ} )$Boolean = TRUE if the pixel ° d ONLN d1q8}Y )¥(word) ° d ONLN d;} Ñâ_ (• ¢3offset falls within the left side of the character. ◊ 4◊˘
(Ï 66 ) of 7 (ÏY%Styled TextEdit Changes in System 6.0 ˇ‰ ◊# ˇ ˇˇˇˇ # ◊
IR , Times
. +Z-Developer Support Center ( -fi
December 1988 / X /
° d ONLN d < , ‚ ( H ZTextEdit Data Structures
° d ONLN d 8 < DÎ *SThe illustration on the following page is a graphic representation of the TextEdit ° d ONLN d l 8Î D˛ ( ` data ° d ONLN d q D < P€ ( l ZVstructures. You should use this information only for debugging and so you understand ° d ONLN d « D€ P˛ ( l˘what is ° d ONLN d œ P < \ p ( x Z going on. ° d ONLN d ⁄ P p \˛ )4SFor reading or writing these data structures, the TextEdit routines should be used. ° d ONLN d. \ < h ( Ñ Z+This will help ensure future compatibility. ° d ONLN dZ å < ò ¶ *0Further Reference: ∑ X ∑ ° d ONLN dm ô N • R +
• ° d ONLN do ô ` • fi )M.OV.GestaltSysenvirons ◊ X◊
(Ï Z%Styled TextEdit Changes in System 6.0 (Ï7 ) of 7 ˇ t ◊# ˇ ˇˇˇˇ # ◊ ° d WORD S † å ° d WORD R… † Ç
/ Z Å#
0Ià:µú9 " { ˇˇˇˇˇˇˇˇ # † ƒ ° d
ONLN f ˛ † å ° d 1drw2 … -·_ Ä ˇˇˇˇˇˇ è ° ñ x ° d drw2 : ° d drw2 : $ ° d 4drw2 : ° ö ˇ˙ ó@ † ò , Times
. WIQkWIQk +]BNew Technical Notes † ô ° d drw2 : °„ † ó ° d 1drw2 eÙ Ä ˇˇˇˇˇˇ P ° ñ x ° d drw2 : ° d drw2 : $ ° d 4drw2 : ° ö ˇ˚Ä E¿ † ò
Ä ( {ïDeveloper Support † ô ° d drw2 : °„ † ó ° d `drw2 - Ô ˇˇˇˇˇˇ K Ô - Z f f Z ° d 1drw2 ¿˙È ˇˇˇˇˇˇ K ° ñ x ° d drw2 : ° d drw2 : $ ° d 4drw2 : 0 ° ö ˇÙ Ä † ò
0 ( UÔ † ô ° d drw2 : °„ † ó ° d 1drw2 ÔÊ˙ ˇˇˇˇˇˇ ° ñ x ° d drw2 : ° d drw2 : $ ° d 4drw2 : ° ö ˇ˝Ä † ò
l +& ® † ô ° d drw2 : °„ † ó ° d 1drw2  -¯ y ˇˇˇˇˇˇ ° ñ x ° d drw2 : ° d drw2 : $ ° d 4drw2 : ° ö ˇ˚Ä % † ò
BÄ ( Z \ Macintosh † ô ° d drw2 : °„ † ó † ç ° d drw2 D † É ° d WORD † ç
IR . ° d ONLN d { < é ¨ ( ® Z TEScroll Bug
° d ONLN d
ç < ú Z *Text ° d ONLN d ç} ú˛ ( ∏õM.TE.TEScrollBug
° d ONLN d $ ® < ¥ t ( – Z Revised by: ° d ONLN d 1 ®≈ ¥˛ ( –„
March 1988 ° d ONLN d < ¥ < ¿ q ( ‹ Z Written by: ° d ONLN d H ¥ Ñ ¿ « )H
Bryan Stearns ° d ONLN d V ¥À ¿˛ ( ‹È
April 1986 Î X Î ° d ONLN d a ⁄ < Ê5 ( Z2A bug in TextEdit causes the following problem: a ° d ONLN d ì ⁄5 ÊX )˘call to ,
Courier ° d ONLN d õ ŸX Âê )#TEScroll ° d ONLN d £ ⁄ê Ê˛ )8 with no horizontal or ° d ONLN d ∫ Á < Û Í ( Z%vertical displacement (that is, both ° d ONLN d fl Ê Í Ú ¯ )Ædh ° d ONLN d · Á ¯ Û ) and ° d ONLN d Ê Ê Ú! )dv ° d ONLN d Ë Á! ÛF ) set to ° d ONLN d ÁF Û˛ )%%zero) results in disappearance of the ° d ONLN d Û < ˇ ( ZEinsertion point. Since such calls do nothing, they should be avoided:
° d ONLN d] `Ç +$:IF (dh <> 0) OR (dv <> 0) THEN TEScroll(dh,dv,myTEHandle);
° d ONLN dò9 <E ¶ (a ZFurther Reference: d Xd ° d ONLN d´F NR R +
• ° d ONLN d≠F `R à )TextEdit ° d ONLN d∂R N^ R (z l• ° d ONLN d∏R `^ ¡ )M.TE.TextEditBugs ◊ X◊
(Ï Z TEScroll Bug (Ï1 ) of 1 ˇ ° ¿Ù%%DSIDICT:_cv
currentdict /bu known {bu}if
userdict /_cv known not{userdict /_cv 30 dict put}if
_cv begin
/bdf{bind def}bind def
currentscreen/cs exch def/ca exch def/cf exch def
/setcmykcolor where{/setcmykcolor get /cvcmyk exch def}{/cvcmyk{1 sub 4 1 roll 3{3 index add neg dup 0 lt{pop 0}if 3 1 roll}repeat setrgbcolor pop}bdf }ifelse
/ss{//cf //ca //cs setscreen}bdf
/stg{ss setgray}bdf
/strgb{ss setrgbcolor}bdf
/stcmyk{ss cvcmyk}bdf
/min1{dup 0 eq{pop 1}if}bdf
end
currentdict /bn known {bn}if
† ø ◊# ˇ ˇˇˇˇ # ◊ † Ç
/ Z Å#
0Ià:µú9 " { ˇˇˇˇˇˇˇˇ # † ƒ ° d
ONLN f ˛ † å ° d 1drw2 … -·_ Ä ˇˇˇˇˇˇ è ° ñ x ° d drw2 : ° d drw2 : $ ° d 4drw2 : ° ö ˇ˙ ó@ † ò , Times
. R… R… +]BNew Technical Notes † ô ° d drw2 : °„ † ó ° d 1drw2 eÙ Ä ˇˇˇˇˇˇ P ° ñ x ° d drw2 : ° d drw2 : $ ° d 4drw2 : ° ö ˇ˚Ä E¿ † ò
( {ïDeveloper Support † ô ° d drw2 : °„ † ó ° d `drw2 - Ô ˇˇˇˇˇˇ K Ô - Z f f Z ° d 1drw2 ¿˙È ˇˇˇˇˇˇ K ° ñ x ° d drw2 : ° d drw2 : $ ° d 4drw2 : 0 ° ö ˇÙ Ä † ò
0 ( UÔ † ô ° d drw2 : °„ † ó ° d 1drw2 ÔÊ˙ ˇˇˇˇˇˇ ° ñ x ° d drw2 : ° d drw2 : $ ° d 4drw2 : ° ö ˇ˝Ä † ò
+& ® † ô ° d drw2 : °„ † ó ° d 1drw2  -¯ y ˇˇˇˇˇˇ ° ñ x ° d drw2 : ° d drw2 : $ ° d 4drw2 : ° ö ˇ˚Ä % † ò
( Z \ Macintosh † ô ° d drw2 : °„ † ó † ç ° d drw2 D † É
IR . ° d ONLN d z < ç% ( ß ZTextEdit: Advice & Descent
° d ONLN d å < õ Z *Text ° d ONLN d ! åk õ˛ ( ∑âM.TE.TextEditAdvice
° d ONLN d 5 ß < ≥ t ( œ Z Revised by: ° d ONLN d B ß≈ ≥˛ ( œ„
March 1988 ° d ONLN d M ≥ < ø q ( € Z Written by: ° d ONLN d Y ≥ Ñ ø ¥ )H
Rick Blair ° d ONLN d d ≥Õ ø˛ ( €Î June 1986 ° d ONLN d n À < ◊Ù ( Û ZYThis technical note will point out some bugs (and possible workarounds), and other items ° d ONLN d « ÀÙ ◊˛ ( Ûof ° d ONLN d ◊ < „ Ï ( ˇ Z%interest for the TextEdit programmer. X ° d ONLN d ¸ < w *% TESelRect ° d ONLN d ˙ < ‹ *#Multiple line selections are often ° d ONLN d ‹ ˛ )†:more complex shapes than simple rectangles. If this is the ° d ONLN dX! <- l (I Z
call (where ° d ONLN d ‹‚Ë )@D4 ° d ONLN d›È˛ ) is ° d ONLN dÍ <ˆ ÷ ( Z!ignored as it’s assumed to equal ° d ONLN d'È ÷ı ‰ )öD3 ° d ONLN d)Í ‰ˆ )), etc. ° d ONLN d1 < ~ (+ ZNote that the ° d ONLN d? ~ Ø )BDoCaret ° d ONLN dF Ø )1 (–2) call behaves ° d ONLN dY ò )Z differently than described in ° d ONLN dwòÎ )èInside Macintosh ° d ONLN dáβ )S, as ° d ONLN då <) (7 Z,well. Good old page 391 says it sets up the ° d ONLN d∏)˛ )Ì(pen position for caret drawing. Since an ° d ONLN d· <' Ç (D Z
InvertRect ° d ONLN dÎ Ç(s )F7 call is used to draw the caret if you use the default ° d ONLN d"s'≤ )Ò teCarHook ° d ONLN d+ ≤( )?, the ° d ONLN d1 (˛ ) ROMs just ° d ONLN d;) <5 [ (Q Zset up ° d ONLN dB( [4 ö ) teSelRect ° d ONLN dK) ö5l )?+, they don’t bother with the QuickDraw pen. ° d ONLN dwA <M ç (i Z TEScrpLength ° d ONLN dÑZ <f ø *Inside Macintosh describes ° d ONLN düY øe )É TEScrpLength ° d ONLN d´Zfè )T as a long integer; indeed, ° d ONLN d«Zèf˛ )|four bytes are reserved ° d ONLN dflf <r ¶ (é Zfor this value with the ° d ONLN d˜f ¶r˛ )jCintent of someday using that range of values. However, the ROMs use ° d ONLN d;s < Á (õ Z%word operations in their accesses to ° d ONLN d`r Á~; )´ TEScrpLength ° d ONLN dls;È )T% and make word calculations with it. ° d ONLN dësÈ˛ )ÆThis ° d ONLN dñÄ <å … (® Z means that the high word of ° d ONLN d≤ …ã )ç TEScrpLength ° d ONLN dæÄ åò )T is used for calculations. ° d ONLN dŸÄòå˛ ){This is something to ° d ONLN dÓå <ò (¥ Zwatch out for. ◊ X◊
6viewRect ° d ONLN d& ‚ P Ó ˇ )8%. You will have to save away the old ° d ONLN dK ‚ ˇ Ó‘ )Ø0clipping region, set it out to sufficient size ( ° d ONLN d{ ‚‘ Ó⁄ )’– ° d ONLN d| Ó ˙ > ( 632767, ° d ONLN dÉ Ó > ˙⁄ )&N–32767, 32767, 32767 is probably OK), do your drawing, then restore TextEdit’s ° d ONLN d“ ˙ Î (" 6/clipping area so that it can function properly. ° d ONLN d* 6 Ç *0Further Reference: U 4U˘ ° d ONLN d7 *C . +
• ° d ONLN d7 <C d )TextEdit ° d ONLN d C *O . (k H• ° d ONLN d"C <O ö )M.TE.TEScrollBug ° d ONLN d3O *[ . (w H• ° d ONLN d5O <[ § )M.TE.EOLAmbiguity ° d ONLN dG[ *g . (É H• ° d ONLN dI[ <g ù )M.TE.TextEditBugs ◊ 4◊˘
(Ï 62 ) of 2 (ÏàTextEdit: Advice & Descent ˇÍ ◊# ˇ ˇˇˇˇ # ◊ ° d WORD S † å ° d WORD R… † Ç
/ Z Å#
0Ià:µú9 " { ˇˇˇˇˇˇˇˇ # † ƒ ° d
ONLN f ˛ † å ° d 1drw2 … -·_ Ä ˇˇˇˇˇˇ è ° ñ x ° d drw2 : ° d drw2 : $ ° d 4drw2 : ° ö ˇ˙ ó@ † ò , Times
. WIQkWIQk +]BNew Technical Notes † ô ° d drw2 : °„ † ó ° d 1drw2 eÙ Ä ˇˇˇˇˇˇ P ° ñ x ° d drw2 : ° d drw2 : $ ° d 4drw2 : ° ö ˇ˚Ä E¿ † ò
Ä ( {ïDeveloper Support † ô ° d drw2 : °„ † ó ° d `drw2 - Ô ˇˇˇˇˇˇ K Ô - Z f f Z ° d 1drw2 ¿˙È ˇˇˇˇˇˇ K ° ñ x ° d drw2 : ° d drw2 : $ ° d 4drw2 : 0 ° ö ˇÙ Ä † ò
0 ( UÔ † ô ° d drw2 : °„ † ó ° d 1drw2 ÔÊ˙ ˇˇˇˇˇˇ ° ñ x ° d drw2 : ° d drw2 : $ ° d 4drw2 : ° ö ˇ˝Ä † ò
l +& ® † ô ° d drw2 : °„ † ó ° d 1drw2  -¯ y ˇˇˇˇˇˇ ° ñ x ° d drw2 : ° d drw2 : $ ° d 4drw2 : ° ö ˇ˚Ä % † ò
BÄ ( Z \ Macintosh † ô ° d drw2 : °„ † ó † ç ° d drw2 D † É ° d WORD † ç
IR . ° d ONLN d { < é* ( ® ZTextEdit Bugs in System 4.2
° d ONLN d ç < ú Z *Text ° d ONLN d " çy ú˛ ( ∏óM.TE.TextEditBugs
° d ONLN d 4 ® < ¥ t ( – Z Revised by: ° d ONLN d A ®≈ ¥˛ ( –„
March 1988 ° d ONLN d L ¥ < ¿ q ( ‹ Z Written by: ° d ONLN d X ¥ Ñ ¿ ≈ )H
Chris Derossi ° d ONLN d f ¥ ¿˛ ( ‹Ë
June 1987 ° d ONLN d q à < ÿ ö ( Ù ZThis note formerly ° d ONLN d Ñ Ã ö ÿ˛ )^Edescribed the known bugs with the version of Styled TextEdit that was ° d ONLN d ÿ < ‰ Ê ( Z provided with System 4.1. Many ° d ONLN d È ÿ Ê ‰˛ )™4of these bugs were fixed in System 4.2. This updated ° d ONLN d ‰ < L ( Z6Technical Note describes the remaining known problems. X
° d ONLN dU <$ ë *4 TEStylInsert
° d ONLN db1 <= a *Calling ,
Courier ° d ONLN dj0 a< µ )% TEStylInsert ° d ONLN dv1 µ== )T while the TextEdit record is ° d ONLN dî1==˛ )à)deactivated causes unpredictable results, ° d ONLN dæ> <J ¥ (f Zso make sure to only call ° d ONLN dÿ= ¥I )x TEStylInsert ° d ONLN d‰>JØ )T$ when the TextEdit record is active.
° d ONLN d b <q Ö (ç Z
TESetStyle
° d ONLN d~ <ä x * When using ° d ONLN d ~ xä ä )<the ° d ONLN d#} äâ ¥ )doFace ° d ONLN d)~ ¥ä Ô )* mode with ° d ONLN d4} Ôâ5 );
TESetStyle ° d ONLN d>~5ä˛ )F+, the style that you pass as a parameter is ° d ONLN djä <ñ X (≥ ZORed ° d ONLN dnã XóE ) 7 into the style of the currently selected text. If you ° d ONLN d•ãEó˛ )Ì&pass the empty set (no styles) though, ° d ONLN dÃó <£ Ç (¿ Z
TESetStyle ° d ONLN d÷ò ǧ[ )F+ is supposed to remove all styles from the ° d ONLN dò[§∏ )Ÿselected text. But ° d ONLN dó∏£˛ )]
TESetStyle ° d ONLN d • <±C (Õ Z5checks an entire word instead of just the high-order ° d ONLN dT•C±Å (Õa byte of the ° d ONLN d`§Å∞´ )>tsFace ° d ONLN df•´±˛ )* field. The style ° d ONLN dx± <Ωy (Ÿ ZDinformation is contained completely in the high-order byte, and the ° d ONLN dº±yΩ˛ (Ÿólow-order byte may contain ° d ONLN d◊Ω <… e ( Zgarbage. ° d ONLN d‡÷ <‚ ‘ *"If the low-order byte isn’t zero, ° d ONLN d’ ‘· )ò
TESetStyle ° d ONLN d ÷‚= )F thinks ° d ONLN d÷=‚d )# that the ° d ONLN d ’d·é )'tsFace ° d ONLN d#÷邲 )* field isn’t empty, so it ° d ONLN d=‚ <ÓG (
Z6goes ahead and ORs it with the selected text’s style. ° d ONLN ds‚GÓ˛ (
e%Since the actual style portion of the ° d ONLN dôÓ <˙ f ( ZtsFace ° d ONLN düÔ f˚ É )* field ° d ONLN d¶Ô É˚∏ ) =is zero, no change occurs with the text. If you want to have ° d ONLN d„Ó∏˙˛ (÷
TESetStyle ° d ONLN dÓ¸ <H ($ Z<remove all styles from the text, you can explicitly set the ° d ONLN d*˚Hr ($ftsFace ° d ONLN d0¸rÿ )* field to zero like this:
° d ONLN dK ` o (; ~VAR ° d ONLN dP `) ÿ *
myStyle : TextStyle; ° d ONLN dj( `3 ” *
anIntPtr : ^Integer; ° d ONLN dÉ< `G y *BEGIN ° d ONLN däF `Q ~ *
(Ï ZTextEdit Bugs in System 4.2 (Ï1 ) of 2 ˇ ° ¿Ù%%DSIDICT:_cv
currentdict /bu known {bu}if
userdict /_cv known not{userdict /_cv 30 dict put}if
_cv begin
/bdf{bind def}bind def
currentscreen/cs exch def/ca exch def/cf exch def
/setcmykcolor where{/setcmykcolor get /cvcmyk exch def}{/cvcmyk{1 sub 4 1 roll 3{3 index add neg dup 0 lt{pop 0}if 3 1 roll}repeat setrgbcolor pop}bdf }ifelse
/ss{//cf //ca //cs setscreen}bdf
/stg{ss setgray}bdf
/strgb{ss setrgbcolor}bdf
/stcmyk{ss cvcmyk}bdf
/min1{dup 0 eq{pop 1}if}bdf
end
currentdict /bn known {bn}if
† ø ◊# ˇ ˇˇˇˇ # ◊
IR , Times
. +6-Macintosh Technical Notes / 4 /˘
° d ONLN d ) 8 c *' TEStylNew
° d ONLN d
E Q
*5The line heights array does not get initialized when ,
Courier ° d ONLN d ? D
PI )Ú TEStylNew ° d ONLN d H EI QW )? is ° d ONLN d L EW Q⁄ ) called. Because of this, the ° d ONLN d i R ^ ô ( z 6 caret is initially drawn in ° d ONLN d Ö R ô ^õ )Å2a random height. This is easily solved by calling ° d ONLN d ∑ Qõ ]⁄ ( zπ TECalText ° d ONLN d ¡ _ k ö ( á 6immediately after calling ° d ONLN d € ^ ö j Ÿ )Ç TEStylNew ° d ONLN d ‰ _ Ÿ k0 )?. Extra calls to ° d ONLN d ı ^0 jo )W TECalText ° d ONLN d ˛ _o kñ )? don’t ° d ONLN d _ñ k⁄ )'
then call ° d ONLN dŒ ∂ B ¬ z )*TextSize ° d ONLN d÷ ∑ z √= )8, with a small value (like 9) before calling ° d ONLN d ∂= ¬| )√ TEStylNew ° d ONLN d ∑| √Ä )?.
° d ONLN d
€ Í T ( 6TEScroll
° d ONLN d ˜ 8 *6The bug documented in M.TE.TEScrollBug remains in the ° d ONLN dL ˜8Ç ( Vnew TextEdit. ° d ONLN dZ ˆÇ∫ )JTEScroll ° d ONLN db ˜∫⁄ )8 called ° d ONLN dj S (+ 6Dwith zero for both vertical and horizontal displacements causes the ° d ONLN dÆS⁄ (+q insertion point to disappear. ° d ONLN dà O (8 6>The workaround is the same as before; check to make sure that ° d ONLN d
O] (8mdV ° d ONLN d ] v ) and ° d ONLN dvÑ )dH ° d ONLN dÑ Δ ) are not both ° d ONLN d!Δ ⁄ )Bzero ° d ONLN d& ) [ (E 6before calling ° d ONLN d5 [( ì )CTEScroll ° d ONLN d= ì) ó )8.
° d ONLN d?A P ≈ (l 6Growing TextEdit Record
° d ONLN dW] i( *8TextEdit is supposed to dynamically grow and shrink the ° d ONLN dè\(hn (ÖF
*p2 ) of 2 (ÏÉTextEdit Bugs in System 4.2 ˇ ◊# ˇ ˇˇˇˇ # ◊ † Ç
/ Z Å#
0Ià:µú9 " { ˇˇˇˇˇˇˇˇ # † ƒ ° d
ONLN f ˛ † å ° d 1drw2 … -·_ Ä ˇˇˇˇˇˇ è ° ñ x ° d drw2 : ° d drw2 : $ ° d 4drw2 : ° ö ˇ˙ ó@ † ò , Times
. R… R… +]BNew Technical Notes † ô ° d drw2 : °„ † ó ° d 1drw2 eÙ Ä ˇˇˇˇˇˇ P ° ñ x ° d drw2 : ° d drw2 : $ ° d 4drw2 : ° ö ˇ˚Ä E¿ † ò
( {ïDeveloper Support † ô ° d drw2 : °„ † ó ° d `drw2 - Ô ˇˇˇˇˇˇ K Ô - Z f f Z ° d 1drw2 ¿˙È ˇˇˇˇˇˇ K ° ñ x ° d drw2 : ° d drw2 : $ ° d 4drw2 : 0 ° ö ˇÙ Ä † ò
0 ( UÔ † ô ° d drw2 : °„ † ó ° d 1drw2 ÔÊ˙ ˇˇˇˇˇˇ ° ñ x ° d drw2 : ° d drw2 : $ ° d 4drw2 : ° ö ˇ˝Ä † ò
+& ® † ô ° d drw2 : °„ † ó ° d 1drw2  -¯ y ˇˇˇˇˇˇ ° ñ x ° d drw2 : ° d drw2 : $ ° d 4drw2 : ° ö ˇ˚Ä % † ò
( Z \ Macintosh † ô ° d drw2 : °„ † ó † ç ° d drw2 D † É
IR . ° d ONLN d n < Å" ( õ ZTextEdit Conversion Utility
° d ONLN d Ä < è Z *Text ° d ONLN d " Äd è˛ ( ´ÇM.TE.TextEditConvert
° d ONLN d 7 õ < ß t ( √ Z Revised by: ° d ONLN d D õ≈ ߲ ( √„
March 1988 ° d ONLN d O ß < ≥ q ( œ Z Written by: ° d ONLN d [ ß Ñ ≥ œ )HHarvey Alcabes ° d ONLN d j ßÀ ≥˛ ( œÈ
`+ ´ +$UNIT TEConvert; ° d ONLN d 4 `?™ *B {General utilities for conversion between TextEdit and strings} ° d ONLN dbH `S ú * INTERFACE ° d ONLN dp\ `gF *. USES MemTypes,QuickDraw,OSIntf,ToolIntf; ° d ONLN d†p `{á *; PROCEDURE TERecToStr(hTE: TEHandle; VAR str: Str255); ° d ONLN d›z `Öæ *
F {TERecToStr converts the TextEdit record hTE to the string str.} ° d ONLN d%Ñ `èØ *
C {If necessary, the text will be truncated to 255 characters.} ° d ONLN djò `£s *7 PROCEDURE StrToTERec(str: Str255; hTE: TEHandle); ° d ONLN d£¢ `≠√ *
G {StrToTERec converts the string str to the TextEdit record hTE. } ° d ONLN dÏ∂ `¡ µ * IMPLEMENTATION ° d ONLN dˇ `’á *; PROCEDURE TERecToStr(hTE: TEHandle; VAR str: Str255); ° d ONLN d<fi `È ¶ * BEGIN ° d ONLN dLË `Û# *
' GetIText(hTE^^.hText, str); ° d ONLN duÚ `˝ ° *
END; ° d ONLN dÑ `s *7 PROCEDURE StrToTERec(str: Str255; hTE: TEHandle); ° d ONLN dΩ `% ¶ * BEGIN ° d ONLN dÕ$ `/√ *
G TESetText(POINTER(ORD4(@str) + 1), ORD4(length(str)), hTE); ° d ONLN d. `9 ° *
END; ° d ONLN d%B `M t *END.
° d ONLN d*p <| ¶ (ò ZFurther Reference: õ Xõ ° d ONLN d=} Nâ R +
• ° d ONLN d?} `âw )5Macintosh Memory Management: An Introduction TextEdit ◊ X◊
userdict /_cv known not{userdict /_cv 30 dict put}if
_cv begin
/bdf{bind def}bind def
currentscreen/cs exch def/ca exch def/cf exch def
/setcmykcolor where{/setcmykcolor get /cvcmyk exch def}{/cvcmyk{1 sub 4 1 roll 3{3 index add neg dup 0 lt{pop 0}if 3 1 roll}repeat setrgbcolor pop}bdf }ifelse
/ss{//cf //ca //cs setscreen}bdf
/stg{ss setgray}bdf
/strgb{ss setrgbcolor}bdf
/stcmyk{ss cvcmyk}bdf
/min1{dup 0 eq{pop 1}if}bdf
end
currentdict /bn known {bn}if
† øÇ ◊# ˇ ˇˇˇˇ # ◊ ° d WORD S † å ° d WORD R… † Ç
/ Z Å#
0Ià:µú9 " { ˇˇˇˇˇˇˇˇ # † ƒ ° d
ONLN f ˛ † å ° d 1drw2 … -·_ Ä ˇˇˇˇˇˇ è ° ñ x ° d drw2 : ° d drw2 : $ ° d 4drw2 : ° ö ˇ˙ ó@ † ò , Times
. WIQkWIQk +]BNew Technical Notes † ô ° d drw2 : °„ † ó ° d 1drw2 eÙ Ä ˇˇˇˇˇˇ P ° ñ x ° d drw2 : ° d drw2 : $ ° d 4drw2 : ° ö ˇ˚Ä E¿ † ò
Ä ( {ïDeveloper Support † ô ° d drw2 : °„ † ó ° d `drw2 - Ô ˇˇˇˇˇˇ K Ô - Z f f Z ° d 1drw2 ¿˙È ˇˇˇˇˇˇ K ° ñ x ° d drw2 : ° d drw2 : $ ° d 4drw2 : 0 ° ö ˇÙ Ä † ò
0 ( UÔ † ô ° d drw2 : °„ † ó ° d 1drw2 ÔÊ˙ ˇˇˇˇˇˇ ° ñ x ° d drw2 : ° d drw2 : $ ° d 4drw2 : ° ö ˇ˝Ä † ò
l +& ® † ô ° d drw2 : °„ † ó ° d 1drw2  -¯ y ˇˇˇˇˇˇ ° ñ x ° d drw2 : ° d drw2 : $ ° d 4drw2 : ° ö ˇ˚Ä % † ò
BÄ ( Z \ Macintosh † ô ° d drw2 : °„ † ó † ç ° d drw2 D † É ° d WORD † ç
IR . ° d ONLN d { < é ( ® ZTextEdit EOL Ambiguity
° d ONLN d ç < ú Z *Text ° d ONLN d çn ú˛ ( ∏åM.TE.EOLAmbiguity
° d ONLN d / ® < ¥ t ( – Z Revised by: ° d ONLN d < ®≈ ¥˛ ( –„
March 1988 ° d ONLN d G ¥ < ¿ q ( ‹ Z Written by: ° d ONLN d S ¥ Ñ ¿ ∑ )H Rick Blair ° d ONLN d _ ¥Œ ¿˛ ( ‹ÏMay 1987 ,
Courier ° d ONLN d h à < ÿ â ( ı Z TESetSelect ° d ONLN d s Õ â Ÿì )M8 may be used to position the insertion point at the end ° d ONLN d ´ Õì Ÿ˛ ( ı±of a line. There is an ° d ONLN d ¬ Ÿ < µ ( ZQambiguity, though; should the insertion point appear at the end of the preceding ° d ONLN d Ÿµ ² (”line or the start ° d ONLN d%  < ÒÁ (
Z\of the following one? It is possible to determine what will happen, as you are about to see. X ° d ONLN dÇ
<o *%BThere is an internal flag used by TextEdit to determine where the ° d ONLN dƒ
o˛ (2ç insertion point at the end of a ° d ONLN d‰ <# Ê (? Z'line appears. This flag is part of the ° d ONLN d Ê"% )™ clikStuff ° d ONLN d%#] )? field in the ° d ONLN d"]"Ä )8TERec ° d ONLN d'Ä#˛ )# . It is there mainly for the ° d ONLN dD$ <0 \ (L Zuse of ° d ONLN dK# \/ ç ) TEClick ° d ONLN dR$ ç0 ¶ )1, but ° d ONLN dX$ ¶0 ˝ )it is also used by ° d ONLN dk# ˝/J )W TESetSelect ° d ONLN dv$J0˛ )M( (although it defaults to the right side ° d ONLN dü0 << ü (X Zof the previous line). ° d ONLN d∂H <T∞ *RThe following code can be used to force the insertion point to appear at the left ° d ONLN dH∞T˛ (pŒof the following ° d ONLN dT <`] (| Z?line when it is positioned at the end of a line; in MPW Pascal:
° d ONLN dZl `w µ +$TEDeactivate(tH); ° d ONLN dmv `Å Œ *
tH^^.clikStuff := 255; ° d ONLN dÜv8Å∞ )ÿ{position caret on left} ° d ONLN d†Ä `ã( (ß ~(TESetSelect(eolcharpos, eolcharpos, tH); ° d ONLN d…Ä8ãç )ÿ{ambiguous point} ° d ONLN d‹ä `ï ´ (± ~TEActivate(tH);
° d ONLN dφ <¨ s (» Z In MPW C:
° d ONLN d˜∏ `√ µ +$TEDeactivate(tH); ° d ONLN d
¬ `Õ ” *
(**tH).clikStuff = 255; ° d ONLN d$¬8Õ∫ )ÿ/*position caret on left*/ ° d ONLN d@Ã `◊( (Û ~(TESetSelect(eolcharpos, eolcharpos, tH); ° d ONLN diÃ8◊ó )ÿ/*ambiguous point*/ ° d ONLN d~÷ `· ´ (˝ ~TEActivate(tH);
° d ONLN déÏ <¯ Í ( Z%If you want to ensure that the caret ° d ONLN d≥Ï Í¯˛ )Æ9is on the right side (to which it normally defaults) then ° d ONLN d̯ < √ ( Z substitute a zero for the 255. ° d ONLN d ( <4 ¶ *0Further Reference: S XS ° d ONLN d 5 NA R +
• ° d ONLN d!5 `A ± )Inside Macintosh ° d ONLN d15 ±Ae )Q$, Volume V, Compatibility Guidelines ° d ONLN dVA NM R (i l• ° d ONLN dXA `M fi )M.OV.GestaltSysenvirons ◊ X◊
userdict /_cv known not{userdict /_cv 30 dict put}if
_cv begin
/bdf{bind def}bind def
currentscreen/cs exch def/ca exch def/cf exch def
/setcmykcolor where{/setcmykcolor get /cvcmyk exch def}{/cvcmyk{1 sub 4 1 roll 3{3 index add neg dup 0 lt{pop 0}if 3 1 roll}repeat setrgbcolor pop}bdf }ifelse
/ss{//cf //ca //cs setscreen}bdf
/stg{ss setgray}bdf
/strgb{ss setrgbcolor}bdf
/stcmyk{ss cvcmyk}bdf
/min1{dup 0 eq{pop 1}if}bdf
end
currentdict /bn known {bn}if
† ø Ü ◊# ˇ ˇˇˇˇ # ◊ † Ç
/ Z Å#
0Ià:µú9 " { ˇˇˇˇˇˇˇˇ # † ƒ ° d
ONLN f ˛ † å ° d 1drw2 … -·_ Ä ˇˇˇˇˇˇ è ° ñ x ° d drw2 : ° d drw2 : $ ° d 4drw2 : ° ö ˇ˙ ó@ † ò , Times
. R… R… +]BNew Technical Notes † ô ° d drw2 : °„ † ó ° d 1drw2 eÙ Ä ˇˇˇˇˇˇ P ° ñ x ° d drw2 : ° d drw2 : $ ° d 4drw2 : ° ö ˇ˚Ä E¿ † ò
( {ïDeveloper Support † ô ° d drw2 : °„ † ó ° d `drw2 - Ô ˇˇˇˇˇˇ K Ô - Z f f Z ° d 1drw2 ¿˙È ˇˇˇˇˇˇ K ° ñ x ° d drw2 : ° d drw2 : $ ° d 4drw2 : 0 ° ö ˇÙ Ä † ò
0 ( UÔ † ô ° d drw2 : °„ † ó ° d 1drw2 ÔÊ˙ ˇˇˇˇˇˇ ° ñ x ° d drw2 : ° d drw2 : $ ° d 4drw2 : ° ö ˇ˝Ä † ò
+& ® † ô ° d drw2 : °„ † ó ° d 1drw2  -¯ y ˇˇˇˇˇˇ ° ñ x ° d drw2 : ° d drw2 : $ ° d 4drw2 : ° ö ˇ˚Ä % † ò
( Z \ Macintosh † ô ° d drw2 : °„ † ó † ç ° d drw2 D † É
IR . ° d ONLN d z < ç£ ( ß Z*TextEdit Record Size Limitations Revisited
° d ONLN d + å < õ Z *Text ° d ONLN d 1 åd õ˛ ( ∑ÇM.TE.RecordSizeLimit
° d ONLN d F ß < ≥ q ( œ Z Written by: ° d ONLN d R ß Ñ ≥ æ )H
Mary Walsh ° d ONLN d ] ßÕ ≥˛ ( œÎ June 1989 ° d ONLN d g ø < À” ( Á ZOThis Technical Note describes another limit on the length of a TextEdit record ° d ONLN d ∂ ø” À˛ ( ÁÒthat was ° d ONLN d ø À < ◊ ∫ ( Û Zpreviously undocumented. X ° d ONLN d ÿ < ¸ ∫ *%The TextEdit chapters in ° d ONLN d Ò ∫ ¸
)~Inside Macintosh ° d ONLN d
¸÷ )S' document the 32K character limit on a ° d ONLN d( ÷ ¸˛ )…TextEdit ° d ONLN d1 ¸ <" ($ Z.record length. They do not, however, discuss ° d ONLN d_ ¸"˛ )Ê-the more subtle constraint on the size of the ,
Courier ° d ONLN dç < t (1 ZdestRect ° d ONLN dï t Ÿ )8. By definition, the ° d ONLN d´ Ÿ )edestRect ° d ONLN d≥ . )8 uses ° d ONLN dπ .˙ ) *integer values for the top-left and bottom ° d ONLN d„ ˙˛ )Ã- ° d ONLN d‰ <"à (> ZDright boundary points. It is possible to have values too large for ° d ONLN d(à"ú (>¶the ° d ONLN d,ú!‘ )destRect ° d ONLN d4‘"˛ )8 without ° d ONLN d=# </ x (K Z
lineHeight ° d ONLN d´<‰H˛ )F field ° d ONLN d≤H <T@ (p Z:specifies the vertical distance from the ascent line from ° d ONLN dÏH@T˛ (p^*one line of text to the ascent line of the ° d ONLN dU <a ⁄ (} Z$next line. In styled TextEdit, the ° d ONLN d;T ⁄` )û
lineHeight ° d ONLN dEU a# )F ° d ONLN dFU#a˛ ),may vary for each line depending on the font ° d ONLN dsb <n (ä Z0and font size. These values are entries in the ° d ONLN d£amX )÷
IR ° d ONLN dµÍ ‚ˆX ( Figure 1–LineHeight ° d ONLN d… < x (+ Z The product ° d ONLN d’ x ò )<of the ° d ONLN d‹ ò fi )
lineHeight ° d ONLN dÊ fi) )F (or the largest ° d ONLN d˜)o )K
lineHeight ° d ONLN do˛ )F value in styled TextEdit) and ° d ONLN d < f (8 ZnLines ° d ONLN d& f ¶ )*E gives a good approximation, in pixels, of the vertical dimension of ° d ONLN dk¶ ∏ (8ƒthe ° d ONLN do∏ )destRect ° d ONLN dw ˛ )8 of ° d ONLN d{ <) M (E Zthe ° d ONLN d M( p )TERec ° d ONLN dÑ p) ê )# used. ° d ONLN dã ê)˛ ) N If this value is greater than 32,768, then unpredictable and erratic behavior ° d ONLN d⁄) <5 q (Q Z may result. ° d ONLN dÊA <M z * For example: ° d ONLN dÙZ `f +$'2,400 lines of Chicago 12 point yields ° d ONLN dYeB )∏nLines ° d ONLN d!ZBfÇ )*
= 2,400 and ° d ONLN d.YÇe» )@
lineHeight ° d ONLN d8Z»f )F = 16. ° d ONLN dAf `r ä (è ~nLines ° d ONLN dGg äs ñ )* * ° d ONLN dJf ñr ‹ )
lineHeight ° d ONLN dTg ‹s÷ )F4 = 2400 * 16 = 38,400. This is above the 32K limit. ° d ONLN däÄ `å (® ~%1,200 lines of Times 24 point yields ° d ONLN dØã8 )ÆnLines ° d ONLN dµÄ8åx )*
= 1,200 and ° d ONLN d¬xãæ )@
lineHeight ° d ONLN dÃÄæå€ )F = 30. ° d ONLN d‘å `ò ä (µ ~nLines ° d ONLN d⁄ç äô ñ )* * ° d ONLN d›å ñò ‹ )
lineHeight ° d ONLN dÁç ‹ô÷ )F4 = 1200 * 30 = 36,000. This is above the 32K limit. ◊ X◊
(Ï Z*TextEdit Record Size Limitations Revisited (Ï1 ) of 2 ˇ ° ¿Ù%%DSIDICT:_cv
currentdict /bu known {bu}if
userdict /_cv known not{userdict /_cv 30 dict put}if
_cv begin
/bdf{bind def}bind def
currentscreen/cs exch def/ca exch def/cf exch def
/setcmykcolor where{/setcmykcolor get /cvcmyk exch def}{/cvcmyk{1 sub 4 1 roll 3{3 index add neg dup 0 lt{pop 0}if 3 1 roll}repeat setrgbcolor pop}bdf }ifelse
/ss{//cf //ca //cs setscreen}bdf
/stg{ss setgray}bdf
/strgb{ss setrgbcolor}bdf
/stcmyk{ss cvcmyk}bdf
/min1{dup 0 eq{pop 1}if}bdf
end
currentdict /bn known {bn}if
† øÍ ◊# ˇ ˇˇˇˇ # ◊
IR , Times
. +6-Macintosh Technical Notes / 4 /˘
° d ONLN d )F *;In both of the examples above, the number of characters in ° d ONLN d ; F )⁄ ( Ed the edit record was less than ° d ONLN d Y ) 5 > ( Q 632,768.
° d ONLN d a M \ ™ *'Check All Constraints
° d ONLN d w i u 4 *Both ,
Courier ° d ONLN d | h 4 t l ) TELength ° d ONLN d Ñ i l u ” )8 and the size of the ° d ONLN d ô h ” t )gdestRect ° d ONLN d ° i u\ )8 must be under ° d ONLN d ∞ i\ u⁄ )Qthe 32K limit. You can ° d ONLN d » v Ç Q ( û 6 compute an ° d ONLN d ” v Q Ç ˆ )9#approximate vertical height of the ° d ONLN d ˆ u ˆ Å. )•destRect ° d ONLN d ˛ v. Ç∞ )8 by finding the product of ° d ONLN d u∞ Å⁄ )ÇnLines ° d ONLN d É è , ( ´ 6and ° d ONLN d$ Ç , é r )
lineHeight ° d ONLN d. É r è π )F (or the largest ° d ONLN d? Ç π é ˇ )G
lineHeight ° d ONLN dI É ˇ èy )F value in styled TextEdit). ° d ONLN de ≥ ø Ç ( € 6Further Reference: fi 4 fi˘ ° d ONLN dx ¿ * à . +
• ° d ONLN dz ¿ < à ç )Inside Macintosh ° d ONLN dä ¿ ç Ã7 )Q!, Volumes I-371 & V-259, TextEdit ° d ONLN d¨ à * ÿ . ( Ù H• ° d ONLN dÆ Ã < ÿ • )M.OV.ManagerAbuse ◊ 4◊˘
(Ï 62 ) of 2 (ÏJ*TextEdit Record Size Limitations Revisited ˇR ◊# ˇ ˇˇˇˇ # ◊ † Ç
/ Z Å#
0Ià:µú9 " { ˇˇˇˇˇˇˇˇ # † ƒ ° d
ONLN f ˛ † å ° d 1drw2 … -·_ Ä ˇˇˇˇˇˇ è ° ñ x ° d drw2 : ° d drw2 : $ ° d 4drw2 : ° ö ˇ˙ ó@ † ò , Times
. R… R… +]BNew Technical Notes † ô ° d drw2 : °„ † ó ° d 1drw2 eÙ Ä ˇˇˇˇˇˇ P ° ñ x ° d drw2 : ° d drw2 : $ ° d 4drw2 : ° ö ˇ˚Ä E¿ † ò
( {ïDeveloper Support † ô ° d drw2 : °„ † ó ° d `drw2 - Ô ˇˇˇˇˇˇ K Ô - Z f f Z ° d 1drw2 ¿˙È ˇˇˇˇˇˇ K ° ñ x ° d drw2 : ° d drw2 : $ ° d 4drw2 : 0 ° ö ˇÙ Ä † ò
0 ( UÔ † ô ° d drw2 : °„ † ó ° d 1drw2 ÔÊ˙ ˇˇˇˇˇˇ ° ñ x ° d drw2 : ° d drw2 : $ ° d 4drw2 : ° ö ˇ˝Ä † ò
+& ® † ô ° d drw2 : °„ † ó ° d 1drw2  -¯ y ˇˇˇˇˇˇ ° ñ x ° d drw2 : ° d drw2 : $ ° d 4drw2 : ° ö ˇ˚Ä % † ò
( Z \ Macintosh † ô ° d drw2 : °„ † ó † ç ° d drw2 D † É
IR . ° d ONLN d n < Å º ( õ Z
TextEdit Q&As
° d ONLN d Ä < è Z *Text ° d ONLN d Äk è˛ ( ´âM.TX.TextEdit.Q&As
° d ONLN d ' õ < ß t ( √ Z Revised by: ° d ONLN d 3 õ Ñ ß ˇ )HDeveloper Support Center ° d ONLN d L õ¥ ߲ ( √“
December 1992 ° d ONLN d Z ß < ≥ q ( œ Z Written by: ° d ONLN d f ß Ñ ≥ ˇ )HDeveloper Support Center ° d ONLN d ßæ ≥˛ ( œ‹ October 1990 ° d ONLN d å ø < À ⁄ ( Á Z This Technical Note contains a ° d ONLN d ´ ø ⁄ À˛ )û9collection of Q&As relating to a specific topic—questions ° d ONLN d  À < ◊† ( Û ZGyou’ve sent the Developer Support Center (DSC) along with answers from ° d ONLN d, À† ◊˛ ( Ûæthe DSC engineers. ° d ONLN d? ◊ < „ u ( ˇ Z
While DSC ° d ONLN dI ◊ u „˛ )9Lengineers have checked the Q&A content for accuracy, the Q&A Technical Notes ° d ONLN dñ „ < Ô q ( Z don’t have ° d ONLN d° „ q Ô˛ )5Qthe editing and organization of other Technical Notes. The Q&A function is to get ° d ONLN dÛ Ô < ˚ Ÿ ( Z new technical information and ° d ONLN d Ô Ÿ ˚˛ )ù6updates to you quickly, saving the polish for when the ° d ONLN dH ˚ < (# Z,information migrates into reference manuals. ° d ONLN du < k *:Q&As are now included with Technical Notes to make access ° d ONLN dØk ˛ (;â to technical updates easier for ° d ONLN dœ <+. (G Z/you. If you have comments or suggestions about ° d ONLN d˛ .+˛ )Ú*Q&A content or distribution, please let us ° d ONLN d)+ <7 \ (S Zknow ° d ONLN d.+ \7˛ ) Iby sending an AppleLink to DEVFEEDBACK. Apple Partners may send technical ° d ONLN dx7 <Ci (_ Z9questions about Q&A content to DEVSUPPORT for resolution. ° d ONLN d≤O <[ ¨ *New Q&As this month: ° d ONLN d«[ <g * #Extending TextEdit beyond 32K limit ° d ONLN dÎg <s* * *Controlling TEIdle’s insertion point color û Xû
° d ONLN dò <ß7 *4#Extending TextEdit beyond 32K limit
° d ONLN d:ß <≥ x *
Date written: ° d ONLN dHß à≥ ¨ )L9/16/92 ° d ONLN dP≥ <ø Å (€ ZLast reviewed: ° d ONLN d_≥ àø ¨ )L11/1/92 ° d ONLN dgÀ <◊‰ (Û ZVHow do I get around the 32K limit in TextEdit? For example, if I have a 64K text file ° d ONLN dΩÀ‰◊˛ (Ûand I ° d ONLN d√◊ <„Ç (ˇ ZIwant to read it in and display it in a window, I can only read the first ° d ONLN d ◊Ç„˛ (ˇ†32K. How do I make the ° d ONLN d#„ <Ôx ( ZDtext display smoothly when I need to read the next block of text in? ° d ONLN dhÔ <˚ N * ___ ° d ONLN dl <º *JUnfortunately, there’s no supported way of doing this. In the early days, ° d ONLN d∂º˛ (/⁄ TextEdit was ° d ONLN d√ < ” (; Z designed for use primarily with ° d ONLN d„ ” ˛ )ó<the Dialog Manager, for displaying and editing small amounts ° d ONLN d <+/ (G Z4of text at a time. Since then, many developers have ° d ONLN dT /+˛ )Û*used it, or wanted to use it for much more ° d ONLN d+ <7 à (S Z than it was intended. See the ° d ONLN dù+ Ã7˛ )ê;Technical Note “Don’t Abuse the Managers,” available on the ° d ONLN dŸ7 <C π (_ ZDeveloper’s CD, (path: ° d ONLN d7 πC˛ )};“Dev.CD Sept 92:Technical Documentation:Macintosh Technical ° d ONLN d,C <O Ó (k Z"Notes:Overview:Managerial Abuse”). ° d ONLN dO[ <g ¬ *The Word Solution Engine ° d ONLN dh[ ¬g˛ )Ü>by DataPak is a replacement for TextEdit that allows you to go ° d ONLN dßg <s« (è ZSbeyond the 32K limit, as well as including many other features. Other packages are ° d ONLN d˙g«s˛ (è available as ° d ONLN ds < ≤ (õ Zwell. Check the Redgate ° d ONLN d s ≤– )v9Macintosh Directory on AppleLink or publications such as ° d ONLN dXs–˛ (õÓMacTutor ° d ONLN da <ã ® (ß Zmagazine to find them. ◊ X◊
*E
TextEdit Q&As (Ï1 ) of 6 ˇ ° ¿Ù%%DSIDICT:_cv
currentdict /bu known {bu}if
userdict /_cv known not{userdict /_cv 30 dict put}if
_cv begin
/bdf{bind def}bind def
currentscreen/cs exch def/ca exch def/cf exch def
/setcmykcolor where{/setcmykcolor get /cvcmyk exch def}{/cvcmyk{1 sub 4 1 roll 3{3 index add neg dup 0 lt{pop 0}if 3 1 roll}repeat setrgbcolor pop}bdf }ifelse
/ss{//cf //ca //cs setscreen}bdf
/stg{ss setgray}bdf
/strgb{ss setrgbcolor}bdf
/stcmyk{ss cvcmyk}bdf
/min1{dup 0 eq{pop 1}if}bdf
end
currentdict /bn known {bn}if
† øp ◊# ˇ ˇˇˇˇ # ◊
IR , Times
. +6-Macintosh Technical Notes / 4 /˘
° d ONLN d ,2 **Controlling TEIdle’s insertion point color
another idea. ° d ONLN dmà î¶ *JBut, remember, we have a requirement to paint once, and then erase on the ° d ONLN d∑à¶î⁄ (∞ƒ
next pass. ° d ONLN d¬î † « (º 6$Inversion works nicely this way. To ° d ONLN dÊî «†⁄ )Ø6meet this requirement, use Xor mode with PaintRect. As ° d ONLN d † ¨
(» 60you know, Xor mode is “or” mode with the double ° d ONLN dM†
¨⁄ )ı-1s being set to 0 instead of 1. This trait is ° d ONLN d{¨ ∏ñ (‘ 6Oideal in your situation because, always having the same caret pattern, drawing ° d ONLN d ¨ñ∏⁄ (‘¥
a second time ° d ONLN dÿ∏ ƒÃ (‡ 6]obliterates the previous drawing of the caret. Thus, we get the blinking behavior. And, with ° d ONLN d5∏Ã⁄ (‡Íthe ° d ONLN d9ƒ – k (Ï 6Macintosh II and ° d ONLN dJƒ k–⁄ )SJColor QuickDraw, we get these cool things called pixel patterns (IM V-55). ° d ONLN dï– ‹ √ (¯ 6#You can use your own pixel pattern ° d ONLN d∏– √‹⁄ )´;as the pen pattern, bring it in from the resource, and then ° d ONLN dÙ‹ Ë} ( 6Luse PaintRect in the patXor mode to achieve the desired effect. Done, right? ° d ONLN d BÙ π *"Unfortunately, here we run into a ° d ONLN d dÙ π ⁄ )°9major flaw of QuickDraw: It is based on two color models, ° d ONLN d û @ (( 6indexed ° d ONLN d ¶ @ ⁄ )(Uand direct. And, arithmetic operations are performed on the pixel values, and not the ° d ONLN d ¸ µ (4 6Vcolors. In the indexed model, a pixel value of 0x00 is white. (The pixel value in the ° d ONLN d
R µ⁄ (4”indexed ° d ONLN d
Z $
(@ 67color model is really an index into a color table.) If ° d ONLN d
ë
$⁄ )Ú)you Xor it with 0xFF, you’ll get 0xFF, or ° d ONLN d
ª$ 0 £ (L 6 black. If you Xor 0xFF with ° d ONLN d
◊$ £0⁄ )ã?0xFF, you’ll get 0x00 or white again. On the other hand (in the ° d ONLN d 0 < √ (X 6&direct color model), a pixel value of ° d ONLN d =0 √<⁄ )´80x00 is black. If you Xor it with 0xFF, you’ll get 0xFF, ° d ONLN d v< H ú (d 6 or white. This is a problem. ° d ONLN d ìT `Ö *OSo, you’ll need to perform conditional caret coloring (sounds like a disease). ° d ONLN d ‚TÖ`⁄ (|£Depending on the ° d ONLN d Û` l (à 65depth, you’ll need to use a different pixel pattern. ° d ONLN d (`lΩ )Ï#One good way is to use DeviceLoop ( ° d ONLN d K`Ωl⁄ )πInside ° d ONLN d Rl x I (î 6 Macintosh ° d ONLN d [l Ix§ )1G Volume VI, page 21-23). Though it’s included with System 7.0, there’s ° d ONLN d ¢l§x⁄ (î¬ a simulated ° d ONLN d Æx Ñ . († 6one ° d ONLN d ≤x .Ñô )Fas described in the article “Multiple Screens Revealed” on page 57 of ° d ONLN d ¯xôÑæ (†∑develop ° d ONLN d ˇxæÑ⁄ )% #10. ° d ONLN d
Ñ êK (¨ 6>DeviceLoop lets you provide a routine that is called for each ° d ONLN d
CÑKê⁄ (¨i screen that the drawing area ° d ONLN d
`ê ú (∏ 63touches. In this case, the drawing routine is your ° d ONLN d
ìêú⁄ )Í-PaintRect routine for the caret. This drawing ° d ONLN d
¡ú ®≠ (ƒ 6Wroutine gets passed the depth of the screen. So, based on the depth of the screen, you ° d ONLN dú≠®⁄ (ƒÀ can use a ◊ 4◊˘
(Ï 62 ) of 6 (Ïπ
TextEdit Q&As ˇå ◊# ˇ ˇˇˇˇ # ◊
IR , Times
. +Z-Developer Support Center ( -fi
December 1992 / X /
° d ONLN dˇˇ ( E ZVdifferent pixel pattern to draw with. For pixel depth of 32 or direct color mode, you ° d ONLN dˇˇ ( E˜can use ° d ONLN dˇˇ ( Q Z>one pattern, and for the rest you can use a different pattern. ° d ONLN dˇˇ *ENote, the drawing routine used by DeviceLoop allows you to pass in a ° d ONLN dˇˇ ( i™LONGINT of userdata. ° d ONLN dˇˇ ( u ZZWith this longint, you can pass in the pointer to the rectangle from the assembly routine.
° d ONLN dˇˇ *'+Resizing a Macintosh edit field for TEPaste
° d ONLN dˇˇ * Written: ° d ONLN dˇˇ )L11/27/91 ° d ONLN dˇˇ ( ¥ ZLast reviewed: ° d ONLN dˇˇ )L11/27/91 ° d ONLN dˇˇ ( à Z I have a ° d ONLN dˇˇ )(Vsmall edit field and when I call TEPaste, the edit field contents scroll up. How can I ° d ONLN dˇˇ ( ÿ ZMcalculate what the height of the edit field would be after the paste, resize ° d ONLN dˇˇ ( ÿØthe edit field to be that ° d ONLN dˇˇ ( ‰ Z size, and then do the paste? ° d ONLN dˇˇ * ___ ° d ONLN dˇˇ *-There are a couple of ways to implement this: ° d ONLN dˇˇ *
Method #1: ° d ONLN dˇˇ * N1. Set the clip region to something other than the viewRect of the edit field. ° d ONLN dˇˇ * <2. Call TEPaste or TEStylPaste to insert the clipboard text. ° d ONLN dˇˇ * 63. Call TEGetHeight to get the new height of the text. ° d ONLN dˇˇ * C4. Set the viewRect of the TERec to the new height. Call TECalText ° d ONLN dˇˇ (P´for good measure (and ° d ONLN dˇˇ (\ Zgood lineStarts). ° d ONLN dˇˇ * A5. Finally, set the clip region back to normal and call TEUpdate. ° d ONLN dˇˇ *
Method #2: ° d ONLN dˇˇ * V1. Call TENew or TEStylNew to allocate a brand spankin’ new temporary TERec, and give ° d ONLN dˇˇ (å
it a ° d ONLN dˇˇ (ò Z^viewRect and destRect that’s off the screen but that has the same width as the original TERec. ° d ONLN dˇˇ * 2. Next, ° d ONLN dˇˇ )+Qcopy the hText handle of the window’s TERec into the hText field of the temporary ° d ONLN dˇˇ (∞ Z*TERec (good job for BlockMove [IM II-44]). ° d ONLN dˇˇ * Y3. Call TECalText and TEActivate on it; then paste the clipboard text into the temporary ° d ONLN dˇˇ (º¯TERec. ° d ONLN dˇˇ (» ZXSince the view and dest Rects are off the screen, none of this will be seen by the user. ° d ONLN dˇˇ * [4. Call TEGetHeight to get the new height, then copy the text back into the original TERec. ° d ONLN dˇˇ * O5. Finally, call TECalText, then TEUpdate and TEActivate on the original TERec. ° d ONLN dˇˇ * Method #1 has less overhead and ° d ONLN dˇˇ )¶9is a little easier to implement. However, if you have any ° d ONLN dˇˇ ( Zcustom hooks installed in ° d ONLN dˇˇ ){@your TERec, then you probably want to let TextEdit do as much of ° d ONLN dˇˇ ( Z>the work as possible. In this case, method #2 is a better way.
° d ONLN dˇˇ *'6Saving and restoring styled Macintosh TextEdit records
° d ONLN dˇˇ * Written: ° d ONLN dˇˇ )L11/26/90 ° d ONLN dˇˇ (O ZLast reviewed: ° d ONLN dˇˇ )L12/19/90 ° d ONLN dˇˇ (g Z,How do I save and restore Macintosh records ° d ONLN dˇˇ )⁄0created with TextEdit that contain styles? Where ° d ONLN dˇˇ (s Z1can I find additional information or sample code? ° d ONLN dˇˇ * ___ ° d ONLN dˇˇ *;There’s no standard for saving text with styles created by ° d ONLN dˇˇ (óu"TextEdit, so all we can offer is a ° d ONLN dˇˇ (£ ZQrecommendation that’s modeled after the way that TECopy works on styled text. In ° d ONLN dˇˇ (£ styled ° d ONLN dˇˇ (Ø Z_TextEdit, the style information is stored separately from the text rather than embedded within ° d ONLN dˇˇ (Øit. ° d ONLN dˇˇ (ª ZSTECopy maintains this separation when styled text is copied, so our recommendation ° d ONLN dˇˇ (ªÔ maintains ° d ONLN dˇˇ (« Zthis separation, too. ◊ X◊
⁄ )LIvalues of selStart and selEnd after you get the StScrpHandle.) Next, call ° d ONLN d
fi (5 6)GetStylScrap to construct the StScrpRec. ° d ONLN d,
fi⁄ )Δ1You can now save the resulting StScrpRec, perhaps ° d ONLN d^ %* (A 6<in a resource of type 'styl' or in whatever way you see fit. ° d ONLN dõ1 = ∏ *!Reading the text and styles back ° d ONLN dº1 ∏=⁄ )†:into a TextEdit record isn’t much more complicated. First, ° d ONLN d˜= Ix (e 6Jread the text back into a buffer and read the 'styl' resource (or however ° d ONLN dA=xI⁄ (eñyou saved it) into a ° d ONLN dVI U) (q 6:StScrpRec. Create a styled TextEdit record (or use an old ° d ONLN dêI)U⁄ (qG%one), then call TEStylInsert, passing ° d ONLN d∂U a û (} 6 it a pointer to the text buffer ° d ONLN d÷U ûa⁄ )Ü?and a handle to the StScrpRec. Your TextEdit record should then ° d ONLN da m (â 6:contain and display your original styled text. That’s all!
° d ONLN dRy à´ *Macintosh SetClikLoop procedure and TERec clikLoop field
Ù Ã *`The short answer is that the special procedure is a glue routine for shuttling a result between ° d ONLN d
}ÙÃ ⁄ ( Íthe ° d ONLN d
Å º (( 6Xstack and the register D0. The larger question is why does installing clikLoop directly ° d ONLN d
Ÿ º ⁄ ((⁄work? ° d ONLN d
fl ã (4 6C, I think, is the culprit. ° d ONLN d
˚$ 0Ã *ZBut, before I get ahead of myself, let me explain the SetClikLoop procedure. As you know, ° d ONLN d U$Ã0⁄ (LÍthe ° d ONLN d Y0 <û (X 6Tclick loop routine has no parameters but it does return a Boolean result (IM I-380). ,
Courier
° d ONLN d ÆH S! *5FUNCTION MyClikLoop : Boolean; { Pascal declaration } ° d ONLN d ‰R ] *
0pascal Boolean MyClikLoop(); { C declaration }
° d ONLN d h t ¥ * Now, MyClikLoop is called by ° d ONLN d 2h ¥t⁄ )ú9the TextEdit Manager from inside the TEClick routine. The ° d ONLN d lt ÄÆ (ú 6Qway the code was written, TEClick expects to get the Boolean result from D0. For ° d ONLN d ΩtÆÄ⁄ (úÃassembly ° d ONLN d ΔÄ åN (® 6@programmers, this is no problem. In Pascal, the return value is ° d ONLN d
ÄNå⁄ (®lplaced on the stack. So, D0 ° d ONLN d
"å òæ (¥ 6Rdoes not contain your routines’ Boolean and what TEClick grabs will be “who knows ° d ONLN d
tåæò⁄ (¥‹what” ° d ONLN d
zò §. (¿ 6:and your program should crash. SetClikLoop will install a ° d ONLN d
¥ò.§⁄ (¿L#glue routine that calls MyClikLoop. ◊ 4◊˘
(Ï 64 ) of 6 (Ïπ
TextEdit Q&As ˇ* ◊# ˇ ˇˇˇˇ # ◊
IR , Times
. +Z-Developer Support Center ( -fi
December 1992 / X /
° d ONLN d < )< ( E Z5The glue routine will move the result from the stack ° d ONLN d 5 < )˛ ( EZ&to D0. By the way, this information is ° d ONLN d \ ) < 55 ( Q Z-documented on pages 237–238 of Volume Two of ° d ONLN d â )5 5ö )˘Macintosh Revealed, ° d ONLN d ú )ö 5˛ )e Second Edition, by ° d ONLN d ∞ 5 < A ú ( ] ZStephen Chernicoff. ° d ONLN d ƒ M < Y ó *Now why is your ° d ONLN d ‘ M ó Y˛ )[Aprogram causing problems when you use SetClikLoop? You might have ° d ONLN d Y < eŒ ( Å ZPdeclared your MyClikLoop as a C function. Since MyClikLoop takes no parameters, ° d ONLN df YŒ e˛ ( ÅÏ
nothing is ° d ONLN dq e < q≥ ( ç ZRput on the stack. But C, unlike Pascal, places its return value in D0. So, for C, ° d ONLN d√ e≥ q˛ ( ç—the glue routine ° d ONLN d‘ q < }≠ ( ô ZNis not needed. On the other hand, if you use the SetClikLoop routine with a C ° d ONLN d" q≠ }˛ ( ôÀroutine, you will ° d ONLN d4 } < â ( • Z/take the top 2 bytes off the stack and clobber ° d ONLN dc } Ⲡ)’-D0 with the wrong answer. Thus, you might get ° d ONLN dë â < ï l ( ± Z problems. ° d ONLN dõ ° < ≠C *8Though the C routine may work by setting it directly to ° d ONLN d” °C ≠˛ ( …a(the clikLoop field, doing it that way is ° d ONLN d¸ ≠ < π2 ( ’ Z2not the supported method. You should declare your ° d ONLN d. ≠2 π˛ )ˆ(MyClikLoop function as a Pascal function ° d ONLN dW π < ≈ £ ( · Zand use SetClikLoop.
° d ONLN dl › < Ïfl *'=Special handling for Control-P keyboard input in a Mac dialog
° d ONLN d™ Ï < ¯ b * Written: ° d ONLN d≥ Ï à ¯ ¶ )L6/5/91 ° d ONLN d∫ ¯ < Å ( ZLast reviewed: ° d ONLN d… ¯ à ¶ )L8/1/91 ° d ONLN d– < { (8 Z@Under System 6, when Control-P is pressed, a DLE character (hex ° d ONLN d{ ˛ (8ô10) appears in a Macintosh ° d ONLN d+ <(s (D Z<dialog’s editText field. Under System 7, pressing Control-P ° d ONLN dg s(˛ (Dëproduces no change in the ° d ONLN dÅ( <4Ω (P ZGeditText box. The character is fed in via a normal (unaltered) keyDown ° d ONLN d»(Ω4˛ (P€ event fed to ° d ONLN d’4 <@Í (\ ZWDialogSelect. Does Control-P have some special meaning to DialogSelect or TextEdit now? ° d ONLN d-@ <L N * ___ ° d ONLN d1X <d Ù **Believe it or not, and it took several of ° d ONLN d[X Ùd˛ )∏9us scratching our heads to figure this out; yes, it does, ° d ONLN dïd <p ¿ (å Z and this is by design! What ° d ONLN d±d ¿p˛ )Ñ?you are running into is the Dialog Manager and TextEdit working ° d ONLN dÒp <| s (ò Z together to ° d ONLN d˝p s|˛ )7Imake Cut, Copy, and Paste function keys work on an extended keyboard. The ° d ONLN dG| <àé (§ ZEfunction keys on the top of an extended keyboard return $10 as their ° d ONLN då|éà˛ (§¨ASCII keycode. Thus, ° d ONLN d°à <îs (∞ ZCwhen TEKey detects that it is being called from dialog select, and ° d ONLN d‰àsî˛ (∞ë the key you pass is a $10, it ° d ONLN dî <† Æ (º Zthen looks for the event ° d ONLN dî Ɔ˛ )rDrecord on the stack and gets the raw keycode to determine which edit ° d ONLN d`† <¨· (» Z_operation to perform. The bottom line is that it will not then enter the $10 in the edit field. ° d ONLN d¿∏ <ƒ ì *There is a simple ° d ONLN d“∏ ìƒ˛ )WLworkaround, and that is to install a filter proc in your dialog that detects ° d ONLN d ƒ <– (Ï Z*keystrokes (actually it could always just ° d ONLN dIƒ–˛ )≈3look for this certain keystroke) and passes them to ° d ONLN d}– <‹
(¯ Z,TEKey itself, thus skirting the whole issue.
° d ONLN d™Ù <ê *'1Dimming and disabling a specific TEditText object
° d ONLN d‹ < b * Written: ° d ONLN dÂ à ¶ )L8/8/91 ° d ONLN dÏ < Å (7 ZLast reviewed: ° d ONLN d˚ à ¨ )L8/13/91 ° d ONLN d ' <3 j (O ZHow can ° d ONLN d ' j3˛ ).SI dim and disable a specific TEditText object in my TDialogView so the field is not ° d ONLN d _3 <? e ([ Z editable? ° d ONLN d j? <K N * ___ ° d ONLN d nW <c à *The trick is to ° d ONLN d ~W àc˛ )LDuse the TView methods Dimstate and ViewEnable to disable and dim the ° d ONLN d √c <oÆ (ã ZJTEditText Views, and then do a TEditText.StopEdit (which disables editing ° d ONLN d
cÆo˛ (ãÃin the TEditText ° d ONLN d
o <{
(ó Z+box), and in the other case enable dimming ° d ONLN d
Io
{˛ )Œ3and the view itself and use the TEditText.StartEdit ° d ONLN d
}{ <á≈ (£ ZP(which enables editing in the TEditText box), as shown in the C++ example below: ,
Courier
° d ONLN d
Œì <ûö *F anEditText2->DimState(TRUE,kDontRedraw); // disable ° d ONLN d ù <®; *
3 anEditText2->ViewEnable(FALSE,kRedraw); ◊ X◊
*(
TextEdit Q&As (Ï5 ) of 6 ˇÍ ◊# ˇ ˇˇˇˇ # ◊
IR , Times
. +6-Macintosh Technical Notes / 4 /˘ ,
Courier
° d ONLN d ( Ã *$ anEditText2->StopEdit(); ° d ONLN d 1 1 <v *F anEditText1->DimState(FALSE,kDontRedraw); // enable ° d ONLN d x ; F *
2 anEditText1->ViewEnable(TRUE,kRedraw); ° d ONLN d ´ E P
*
1 anEditText1->StartEdit(TRUE,fTEView);
° d ONLN d › [ gï *NMacApp sample code using this technique is included with DTS’s Snippets files.
° d ONLN d, éO *'*Get TEHandle from DialogPeek, not GetDItem
° d ONLN dW é ö > * Written: ° d ONLN d` é d ö à )L1/17/92 ° d ONLN dh ö ¶ ] ( ¬ 6Last reviewed: ° d ONLN dw ö d ¶ à )L2/17/92 ° d ONLN d ≤ æ E ( ⁄ 6
I want to ° d ONLN dâ ≤ E æ⁄ )-Rshow all characters in my Macintosh control panel as bullets where the password is ° d ONLN d‹ æ ı ( Ê 6+typed in. I cannot get the TECustomHook to ° d ONLN d æ ı ⁄ )›.work properly, it crashes before it gets to my ° d ONLN d6 ÷ ( Ú 65hook routine. In the following Think C example, CPtr ° d ONLN dk ÷⁄ ( Ú9'is dereferenced from the handle used in ° d ONLN dì ÷ ‚ æ ( ˛ 6$the control panel’s cdevValue field:
° d ONLN d∏ Ó ˘l *D GetDItem(DPtr, ADMINPWTE+NumItems, &theType, &theItem, &theRect); ° d ONLN d˝ ¯ ÷ *
° d ONLN d\ * * ___ ° d ONLN d`$ 0 „ *(GetDItem does NOT return a TEHandle; it ° d ONLN dà$ „0⁄ )À6returns a handle to the current text of the edit item. ° d ONLN dø0 < Q (X 6 You must ° d ONLN d»0 Q<⁄ )9Cget TEHandle from DialogPeek and must always monitor and change the ° d ONLN d < Hq (d 6ETECustomHook on the fly. There is only one TEHandle for a dialog, no ° d ONLN dQ<qH⁄ (dèmatter how many edit ° d ONLN dfH T∞ (p 6Xitems are associated with the dialog. See the description of the DialogRecord data type ° d ONLN dæH∞TΩ (pŒin ° d ONLN d¡HΩT⁄ )
Inside ° d ONLN d»T ` M (| 6
Macintosh.
° d ONLN d”x áP *'-Cursor flicker while using Macintosh TextEdit
° d ONLN d á ì > * Written: ° d ONLN d á dì Ç )L5/6/92 ° d ONLN dì ü ] (ª 6Last reviewed: ° d ONLN d ì dü à )L9/15/92 ° d ONLN d'´ ∑ fl (” 6*The cursor flashes when the user types in ° d ONLN dQ´ fl∑⁄ )«4TextEdit fields in my Macintosh application. This is ° d ONLN dÜ∑ √U (fl 6Bdone in TEKey. I notice that most programs hide the cursor once a ° d ONLN d»∑U√⁄ (fls key is pressed. I don’t care ° d ONLN dÂ√ œ ÷ (Î 6)for this because then I have to move the ° d ONLN d√ ÷œ⁄ )æ7mouse to see where I am. Is this a typical fix for this ° d ONLN dFœ € ∏ (˜ 6!problem and an accepted practice? ° d ONLN dh€ Á * * ___ ° d ONLN dlÛ ˇ Œ *(There’s very little you can do to avoid ° d ONLN dîÛ Œˇ⁄ )∂6this. The problem is that every time you draw anything ° d ONLN dÀˇ (' 6to the screen, if the ° d ONLN d·ˇ ⁄ )gEcursor’s position intersects the rectangle of the drawing being done, ° d ONLN d' H (3 6?QuickDraw hides the cursor while it does the drawing, and then ° d ONLN df H⁄ (3f shows it again to keep it from ° d ONLN dÖ #ç (? 6Maffecting the image being drawn beneath it. Every time you enter a character ° d ONLN d“ç#⁄ (?´in TextEdit, the ° d ONLN d„# /Œ (K 6]nearby characters are redrawn. Usually this is invisible because the characters just line up ° d ONLN d@#Œ/⁄ (KÏon ° d ONLN dC/ ;≠ (W 6]top of their old images, but if the cursor is nearby and visible, it will flicker while it’s ° d ONLN d†/≠;⁄ (WÀ hidden to ° d ONLN d™; G 4 (c 6draw ° d ONLN dØ; 4G⁄ ) Tthe text. This is why virtually all programs call ObscureCursor when the user types. ° d ONLN d G S fi (o 6)Also, most users don’t want the image of ° d ONLN d -G fiS⁄ )Δ5the cursor obscuring text they might be referring to, ° d ONLN d cS _S ({ 6Byet they don’t want to have to move it away and then move it back ° d ONLN d •SS_⁄ ({qto make selections. Because ° d ONLN d ¡_ k 8 (á 6it’s so ° d ONLN d …_ 8k⁄ ) Tcommonplace, hiding the cursor probably won’t bother your users; in fact, they might ° d ONLN d
k w5 (ì 6<very well prefer the cursor hidden. This, combined with the ° d ONLN d
Zk5w⁄ (ìS%fact that there’s very little you can ° d ONLN d
Äw É√ (ü 6\do to help the flickering, suggests that you should obscure the cursor while the user types. ◊ 4◊˘
*M6 ) of 6 (Ïπ
TextEdit Q&As ˇ2 ◊# ˇ ˇˇˇˇ # ◊ † Ç
/ _ Å(
0Ià:µú9 " { ˇˇˇˇˇˇˇˇ # † ƒ ° d
ONLN f ˛ † å ° d 1drw2 … -·_ Ä ˇˇˇˇˇˇ è ° ñ x ° d drw2 : ° d drw2 : $ ° d 4drw2 : ° ö ˇ˙ ó@ † ò , Times
. R… R… +bBNew Technical Notes † ô ° d drw2 : °„ † ó ° d 1drw2 eÙ Ä ˇˇˇˇˇˇ P ° ñ x ° d drw2 : ° d drw2 : $ ° d 4drw2 : ° ö ˇ˚Ä E¿ † ò
( {öDeveloper Support † ô ° d drw2 : °„ † ó ° d `drw2 - Ô ˇˇˇˇˇˇ K Ô - Z f! f _ ° d 1drw2 ¿˙È ˇˇˇˇˇˇ K ° ñ x ° d drw2 : ° d drw2 : $ ° d 4drw2 : 0 ° ö ˇÙ Ä † ò
0 ( UÙ † ô ° d drw2 : °„ † ó ° d 1drw2 ÔÊ˙ ˇˇˇˇˇˇ ° ñ x ° d drw2 : ° d drw2 : $ ° d 4drw2 : ° ö ˇ˝Ä † ò
+& ® † ô ° d drw2 : °„ † ó ° d 1drw2  -¯ y ˇˇˇˇˇˇ ° ñ x ° d drw2 : ° d drw2 : $ ° d 4drw2 : ° ö ˇ˚Ä % † ò
( Z a Macintosh † ô ° d drw2 : °„ † ó † ç ° d drw2 D † É
d . ° d ONLN d n < Å ¸ ( õ ZTextEdit Technicalities
° d ONLN d Ä < è Z *Text ° d ONLN d Äy è˛ ( ´óM.TE.TextEditTech
° d ONLN d 0 õ < ß t ( √ Z Revised by: ° d ONLN d < õ Ñ ß Ω )H
Mary Burke ° d ONLN d G õÀ ߲ ( √È
April 1990 ° d ONLN d R ß < ≥ q ( œ Z Written by: ° d ONLN d ^ ß Ñ ≥ Ω )H
Mary Burke ° d ONLN d i ß∏ ≥˛ ( œ÷
February 1990 ° d ONLN d w ø < À‘ ( Á ZNThis Technical Note discusses some areas in TextEdit that have not previously ° d ONLN d ≈ ø‘ À ( ÁÚ been clearly ° d ONLN d “ À < ◊ y ( Û Z documented. ° d ONLN d fi ◊ < „ Ó * Changes since February 1990: ° d ONLN d ˙ ◊ Ó „ú )≤! Added a note about the changes ° d ONLN d ◊ú „ )Æin TextEdit for System ° d ONLN d2 ‰ < ‹ ( Z Software 6.0.5, documented the ° d ONLN dQ ‰ ‹ @ )†low-memory global ,
Courier ° d ONLN dc „@ Ôè )d TESysJust, ° d ONLN dn ‰è )Oclarified information about ° d ONLN dä Ò < ˝ ñ ( Ztext direction and ° d ONLN dù ñ ¸ ‹ )Z
_TESetJust ° d ONLN dß Ò ‹ ˝v )F , discussed problems with the ° d ONLN d≈ v ¸ )ö SetWordBreak ° d ONLN d— Ò ˝œ )T ° d ONLN d“ Òœ ˝ )
routine along ° d ONLN d‡ ˝ < Ó (% Z^with a solution to work around it, and described the differences in dialog text item behavior. 4 X4/
° d ONLN d?. <= Ø *4TextEdit in 6.0.5
° d ONLN dQI <Uô *MIn addition to all the features of earlier versions, TextEdit 3.0 now allows ° d ONLN dûIôU (q∑you to take advantage of ° d ONLN d∑U <a" (} Z.the Script Manager’s handling of systems with ° d ONLN dÂU"a )Ê0more than one script system installed. TextEdit ° d ONLN da <m9 (â Z4uses the Script Manager to support such systems and ° d ONLN dJa9m )˝-now exhibits the correct behavior for editing ° d ONLN dxm <y2 (ï Z5and displaying text in multiple styles and different ° d ONLN d≠m2y )ˆ.scripts. Multiple scripts can even exist on a ° d ONLN d‹y <Ö˘ (° Z_single line due to TextEdit’s use of the Script Manager. The new version of TextEdit in 6.0.5: ° d ONLN d<ë Nù R +• ° d ONLN d>ë [ù Ë )
handles double-byte characters ° d ONLN d°µ N¡ R (› l• ° d ONLN d£µ [¡+ )
*determines word boundaries and line breaks ° d ONLN dŒ¡ NÕ R (È l• ° d ONLN d–¡ [Õ; )
/provides outline highlighting in the background ° d ONLN d Õ NŸ R (ı l• ° d ONLN dÕ [Ÿ& )
)buffers text for performance improvements ° d ONLN d,Ÿ NÂ R ( l• ° d ONLN d.Ÿ [Âe )
?permits left justification in right-to-left directional scripts ° d ONLN dn NÒ R (
l• ° d ONLN dp [Ò ◊ )
customizes word breaking ° d ONLN dâÒ N˝ R ( l• ° d ONLN dãÒ [˝ √ )
customizes measuring ° d ONLN d† < fi (1 Z!Refer to the TextEdit chapter in ° d ONLN d¡ fi1 )¢Inside Macintosh ° d ONLN d— 1: )S, ° d ONLN d” : ) (Volume VI, for detailed documentation on ° d ONLN d¸ <! { (= Z
TextEdit 3.0.
° d ONLN d
9 <H *' The LineStarts Array and nLines
° d ONLN d*U <a Q *The ° d ONLN d.T Q` ó )
LineStarts ° d ONLN d8U óa Ù )F array is a field in a ° d ONLN dOU Ùa )]>TextEdit record that contains the offset position of the first ° d ONLN déa <m v (â Z
character of ° d ONLN dõa vm è ):each ° d ONLN düa èmô )9 line. This array has the following boundary conditions: ¶ X¶/
(ª ZTextEdit Technicalities (ª1 ) of 4 ˇ ° ¿Ù%%DSIDICT:_cv
currentdict /bu known {bu}if
userdict /_cv known not{userdict /_cv 30 dict put}if
_cv begin
/bdf{bind def}bind def
currentscreen/cs exch def/ca exch def/cf exch def
/setcmykcolor where{/setcmykcolor get /cvcmyk exch def}{/cvcmyk{1 sub 4 1 roll 3{3 index add neg dup 0 lt{pop 0}if 3 1 roll}repeat setrgbcolor pop}bdf }ifelse
/ss{//cf //ca //cs setscreen}bdf
/stg{ss setgray}bdf
/strgb{ss setrgbcolor}bdf
/stcmyk{ss cvcmyk}bdf
/min1{dup 0 eq{pop 1}if}bdf
end
currentdict /bn known {bn}if
† øí ◊# ˇ ˇˇˇˇ # ◊
d , Times
. +6-Macintosh Technical Notes / 4 /
° d ONLN d * ) . +• ° d ONLN d 7 ) ¶ )
It is a zero-based array. ° d ONLN d * * 6 . ( R H• ° d ONLN d * 7 6: )
8The last entry in the array must have the same value as ,
Courier ° d ONLN d V ): 5r ( RXteLength ° d ONLN d ^ *r 6v )8. ° d ONLN d ` 6 * B . ( ^ H• ° d ONLN d b 6 7 B )
(The maximum number of entries is 16,000. ° d ONLN d ã O [ ˇ ( w 62To determine the length of a line you can use the ° d ONLN d Ω O ˇ [ä )Á information contained in the ° d ONLN d ⁄ Nä Z– )ã
lineStarts ° d ONLN d ‰ O– [Ï )F array ° d ONLN d Î \ h . ( Ñ 6and ° d ONLN d Ô [ . g X )nLines ° d ONLN d ı \ X hø )*H. For example, if you want to determine the length of line n, subtract ° d ONLN d= \ø hÏ ( Ñ› the value ° d ONLN dG h tN ( ê 6Dcontained in entry n of the array from the value in the entry (n+1):
° d ONLN då Ä ãg *C lengthOfLineN := myTE^^.lineStarts[n+1] - myTE^^.lineStarts[n];
° d ONLN d– ó £ *2The terminating condition for this measurement is ° d ONLN d ó £# )Ìwhen ° d ONLN d ñ# ¢â ) n = nLines + 1 ° d ONLN d óâ £Ï )f. It is important not ° d ONLN d, £ Ø ¸ ( À 61to change the information contained in the array.
° d ONLN d^ « ÷ [ *' TESysJust
° d ONLN dh ‚ Ó W * TESysJust ° d ONLN dq „ W Ô m )? is a ° d ONLN dw „ m ÔÏ )Plow-memory global that specifies the system justification. The default value of ° d ONLN d» Ô ˚~ ( 6Nthis global is normally based on the system script. It is -1 when a system’s ° d ONLN d Ô~ ˚Ï (údefault line direction is ° d ONLN d0 ˚ “ (# 6dright to left, and 0 for a default left-to-right line direction. Applications may change the value ° d ONLN dî ˚“Ï (#using ° d ONLN dö * (0 6the ° d ONLN dû * ü )Script Manager routine ° d ONLN dµ ü Â )u
SetSysJust ° d ONLN dø ÂÏ )F5; however, these applications should save the current ° d ONLN dı … (< 6%value before using it and restore it ° d ONLN d … Ï )±:before exiting the application or processing a MultiFinder ° d ONLN dU , ÿ (H 6"suspend event. The current value ° d ONLN dw ÿ,Ï )¿0may be obtained using the Script Manager routine ° d ONLN d®, 8 ^ (U 6
GetSysJust ° d ONLN d≤- ^9 b )F.
° d ONLN d¥Q ` ≥ (| 6Forcing Text Direction
° d ONLN dÀm y */The original TextEdit documentation introduced ° d ONLN d˙lxL )Ó
_TESetJust ° d ONLN dmLyk )F with ° d ONLN d
mkyÏ ) three possible choices for ° d ONLN d%z Ü X (¢ 6justification: ° d ONLN d5y XÖ û )@
teJustLeft ° d ONLN d?z ûÜ ° )F ° d ONLN d@z °Ü ∑ )(0), ° d ONLN dEy ∑Ö ) teJustCenter ° d ONLN dQz Ü: )T
(1), and ° d ONLN d[y:Öá )/ teJustRight ° d ONLN dfzáÜÏ )M (-1). These choices ° d ONLN d|Ü í › (Æ 6,are appropriate for script systems that are ° d ONLN d®Ü ›íÏ )≈9read from left to right. However, in script systems that ° d ONLN d‚í û (∫ 6;are read from right to left, text is incorrectly displayed ° d ONLN d íûÏ (∫7.as left justified in dialog boxes and in other ° d ONLN dLû ™t (Δ 6Lareas of applications where users cannot explicitly set the justification. ° d ONLN dòût™Ï (ΔíTo fix this problem, the ° d ONLN d±´ ∑ Q (” 6 behavior of ° d ONLN dΩ™ Q∂ ó )9
teJustLeft ° d ONLN d«´ ó∑ ≠ )F has ° d ONLN dô ≠∑Ï )Bchanged to match the line direction of the system in use, which is ° d ONLN d∏ ƒ q (‡ 6the value stored in ° d ONLN d#∑ q√ ∞ )Y TESysJust ° d ONLN d,∏ ∞ƒÅ )?,. Another constant has been added to allow ° d ONLN dX∏ÅƒÏ )—an application to force ° d ONLN dp≈ — j (Ì 6left justification: ° d ONLN dÖƒ j– ∑ )R teForceLeft ° d ONLN dê≈ ∑— Ó )M
(-2). This ° d ONLN dù≈ Ó—Ï )75constant has been available for some time, but it has ° d ONLN d”— › G (˘ 6 not been ° d ONLN d‹— G›Ï )/Pdocumented until now. If your application does not allow the user to change the ° d ONLN d-fi Í ± ( 6"justification, then it should use ° d ONLN dO› ±È ˜ )ô
teJustLeft ° d ONLN dYfi ˜Íw )F ; if it does, then it should ° d ONLN dvfiwÍå )Äuse ° d ONLN dz›åÈŸ ) teForceLeft ° d ONLN dÖfiŸÍÏ )M for ° d ONLN däÍ ˆ e ( 6left justification.
° d ONLN dû ) *'&A Little More on Redraw in _TESetStyle
° d ONLN d≈* 6 6 *If the ° d ONLN dÃ) 65 ` ) redraw ° d ONLN d“* `6 Ω )* parameter used in ° d ONLN dÂ) Ω5
)] _TESetStyle ° d ONLN d*
6 )M is ° d ONLN dÙ)5= )FALSE ° d ONLN d˘*=6Ï )#%, line breaks, line heights, and line ° d ONLN d 6 B$ (^ 6;ascents are not recalculated. Therefore a succeeding call ° d ONLN d Z6$BÏ (^B*to a routine using any of this information ° d ONLN d ÖC ON (k 6Ddoes not reflect the new style information. For example, a call to ° d ONLN d …BNN¢ (kl _TEGetHeight ° d ONLN d ’C¢OÏ )T (which returns ° d ONLN d ÂP \ √ (x 6%a total height between two specified ° d ONLN d
P √\ü )´0lines) uses the line height set previous to the ° d ONLN d
:Oü[Ï )‹ _TESetStyle ° d ONLN d
F] i a (Ö 6call. A call to ° d ONLN d
W\ ah ß )I
_TECalText ° d ONLN d
a] ßi} )F. is necessary to update this information. If ° d ONLN d
è\}hß )÷redraw ° d ONLN d
ï]ßiπ )* is ° d ONLN d
ô\πh’ )TRUE ° d ONLN d
ù]’iÏ ) , the ¶ 4¶
(ª 62 ) of 4 (ªúTextEdit Technicalities ˇ
◊# ˇ ˇˇˇˇ # ◊
d , Times
. +Z-åDeveloper Support Center April 1990 / X //
° d ONLN d < * Δ * current style information is ° d ONLN d Δ *£ )ä,reflected. This behavior also holds for the ,
Courier ° d ONLN d I £ )Õ )›redraw ° d ONLN d O Õ * )*
° d ONLN d | k < w≤ *CThere is currently space reserved for four documented hooks in the ° d ONLN d ø j≤ v
( ì–
TEDispatchRec ° d ONLN d à k
w )[: ° d ONLN d œ w < É { ( † Z TEEolHook ° d ONLN d ÿ x { Ñ Ç )?, ° d ONLN d ⁄ w Ç É œ ) TEWidthHook ° d ONLN d  x œ Ñ ◊ )M, ° d ONLN d Á w ◊ É )
TEDrawHook ° d ONLN d Ò x Ñ6 )F and ° d ONLN d ˆ w6 Éë )
TEHitTestHook ° d ONLN d xë Ñ )[. The space beyond these ° d ONLN d Ñ < êÔ ( ¨ Z_hooks is reserved, and any attempt to use this private area results in corrupted TextEdit data.
° d ONLN d} ® < ∑ … *'Custom Word Breaks
° d ONLN dê ƒ < – q *
A problem ° d ONLN dö ƒ q –a )51exists in one of TextEdit’s advanced procedures, ° d ONLN dÀ √a œµ ) SetWordBreak ° d ONLN d◊ ƒµ – )T. The current glue ° d ONLN dÎ – < ‹œ ( ¯ ZVcode does not preserve the state of the registers correctly; however, the solution is ° d ONLN dA –œ ‹ ( ¯Ìfairly simple. ° d ONLN dQ › < È ê ( ZInstead of calling ° d ONLN dd ‹ ê Ë ‰ )T SetWordBreak ° d ONLN dp › ‰ È¥ )T+ and passing a pointer to your custom word ° d ONLN dõ ›¥ È )–break routine, pass ° d ONLN dØ È < ı+ ( Z4the pointer to your external glue which should call ° d ONLN d„ È+ ı )Ô-your custom word break routine. Following is ° d ONLN d ı < ( Z3the glue code that correctly handles the registers:
° d ONLN dE <$ Ê *#"WordBreakProc PROC EXPORT ° d ONLN dh- <8ö *F IMPORT MYWORDBREAK ;Must be uppercase here ° d ONLN dØ7 <B *
I MOVE.W D0,-(SP) ;Move the charpos to Stack ° d ONLN d´_ <j ˇ *
' JSR MYWORDBREAK ° d ONLN d”i <tY *
9 MOVE.W (SP)+,D0 ;Set Z bit ° d ONLN d
s <~ *
* MOVEM.L (SP)+,D1-D2/A1 ° d ONLN d8} <à † *
RTS ° d ONLN dMë <ú • * ENDP
° d ONLN dcß <≥ ˝ **An external declaration is also necessary:
° d ONLN déø < ¬ *N FUNCTION WordBreakProc( text: Ptr; charPos: INTEGER ) : BOOLEAN; EXTERNAL;
° d ONLN d›’ <·Ü *Ias is the function itself. One thing that should be noted is that it is ° d ONLN d&’Ü· (˝§ not really necessary to have ° d ONLN dC· <Ì â (
Z MyWordBreak ° d ONLN dN‚ âÓ, )M! boolean, but rather to have the ° d ONLN do·,Ì3 )£Z ° d ONLN dp‚3ÓÈ )& bit set properly. The result of the ° d ONLN dñ‚ÈÓ )∂function ° d ONLN düÓ <˙# ( Z-should be zero when you do not want a break; ° d ONLN dÃÓ#˙ )Á0otherwise, a non-zero value indicates a break is ° d ONLN d˝˙ < b (" Zdesired.
° d ONLN d < ê *D FUNCTION MyWordBreak( text : Ptr; charPos : INTEGER ) : INTEGER; ° d ONLN dK <' Ê *
" { Your word break code here. }
° d ONLN dn2 <>< *7For more information, refer to the TextEdit chapter of ° d ONLN d•2<>ç (ZZInside Macintosh ° d ONLN dµ2ç>⁄ )Q, Volume I-380. ¶ X¶/
° d ONLN d D P” *^The Dialog Manager depends on TextEdit to display text in dialog boxes. For an editable text ° d ONLN d w D” PÏ ( lÒfield, ° d ONLN d ~ Q ] ≤ ( y 6 the Dialog Manager simply calls ,
Courier ° d ONLN d û P ≤ \ Ò )ö _TEUpdate ° d ONLN d ß Q Ò ]√ )?.. Before making this call, it may double the ° d ONLN d ’ Q√ ]Ï )“width of ° d ONLN d fi ] i ¨ ( Ö 6"the rectangle to contain the text ° d ONLN d ] ¨ iÏ )îFif the height of the rectangle is sufficient for only one line and the ° d ONLN dG j v X ( í 6line direction ° d ONLN dV j X v ñ )@
ONLN f ˛ † å ° d 1drw2 … -·_ Ä ˇˇˇˇˇˇ è ° ñ x ° d drw2 : ° d drw2 : $ ° d 4drw2 : ° ö ˇ˙ ó@ † ò , Times
. R… R… +]BNew Technical Notes † ô ° d drw2 : °„ † ó ° d 1drw2 eÙ Ä ˇˇˇˇˇˇ P ° ñ x ° d drw2 : ° d drw2 : $ ° d 4drw2 : ° ö ˇ˚Ä E¿ † ò
( {ïDeveloper Support † ô ° d drw2 : °„ † ó ° d `drw2 - Ô ˇˇˇˇˇˇ K Ô - Z f f Z ° d 1drw2 ¿˙È ˇˇˇˇˇˇ K ° ñ x ° d drw2 : ° d drw2 : $ ° d 4drw2 : 0 ° ö ˇÙ Ä † ò
0 ( UÔ † ô ° d drw2 : °„ † ó ° d 1drw2 ÔÊ˙ ˇˇˇˇˇˇ ° ñ x ° d drw2 : ° d drw2 : $ ° d 4drw2 : ° ö ˇ˝Ä † ò
+& ® † ô ° d drw2 : °„ † ó ° d 1drw2  -¯ y ˇˇˇˇˇˇ ° ñ x ° d drw2 : ° d drw2 : $ ° d 4drw2 : ° ö ˇ˚Ä % † ò
( Z \ Macintosh † ô ° d drw2 : °„ † ó † ç ° d drw2 D † É
IR . ° d ONLN d n < Å ƒ ( õ Z
TrueType Q&As
° d ONLN d Ä < è r *Imaging ° d ONLN d Äc è˛ ( ´ÅM.QD.TrueType.Q&As
° d ONLN d ) õ < ß t ( √ Z Revised by: ° d ONLN d 5 õ Ñ ß ˇ )HDeveloper Support Center ° d ONLN d N õæ ߲ ( √‹ October 1992 ° d ONLN d [ ß < ≥ q ( œ Z Written by: ° d ONLN d g ß Ñ ≥ ˇ )HDeveloper Support Center ° d ONLN d Ä ßæ ≥˛ ( œ‹ October 1990 ° d ONLN d ç ø < À ⁄ ( Á Z This Technical Note contains a ° d ONLN d ¨ ø ⁄ À˛ )û9collection of Q&As relating to a specific topic—questions ° d ONLN d Ê À < ◊† ( Û ZGyou’ve sent the Developer Support Center (DSC) along with answers from ° d ONLN d- À† ◊˛ ( Ûæthe DSC engineers. ° d ONLN d@ ◊ < „ u ( ˇ Z
While DSC ° d ONLN dJ ◊ u „˛ )9Lengineers have checked the Q&A content for accuracy, the Q&A Technical Notes ° d ONLN dó „ < Ô q ( Z don’t have ° d ONLN d¢ „ q Ô˛ )5Qthe editing and organization of other Technical Notes. The Q&A function is to get ° d ONLN dÙ Ô < ˚ Ÿ ( Z new technical information and ° d ONLN d Ô Ÿ ˚˛ )ù6updates to you quickly, saving the polish for when the ° d ONLN dI ˚ < (# Z,information migrates into reference manuals. ° d ONLN dv < k *:Q&As are now included with Technical Notes to make access ° d ONLN d∞k ˛ (;â to technical updates easier for ° d ONLN d– <+. (G Z/you. If you have comments or suggestions about ° d ONLN dˇ .+˛ )Ú*Q&A content or distribution, please let us ° d ONLN d*+ <7 \ (S Zknow ° d ONLN d/+ \7˛ ) Iby sending an AppleLink to DEVFEEDBACK. Apple Partners may send technical ° d ONLN dy7 <Ci (_ Z9questions about Q&A content to DEVSUPPORT for resolution. ° d ONLN d≥O <[« *NNew Q&As and Q&As revised this month are marked with a bar in the side margin. "n Ü XÜ
° d ONLN dÄ <èp *4,SetPreserveGlyph and font glyph preservation
° d ONLN d/è <õ b * Written: ° d ONLN d8è àõ ¨ )L7/22/91 ° d ONLN d@õ <ß Å (√ ZLast reviewed: ° d ONLN dOõ àß ¶ )L8/1/92 ° d ONLN dV≥ <ø~ (€ ZBTrueType’s SetPreserveGlyph call with preserveGlyph set to “true” ° d ONLN dò≥~ø˛ (€úworks as you’d expect for ° d ONLN d≤ø <ÀÁ (Á ZSTimes and Helvetica, but it has no effect on New York, Geneva, Monaco, or Chicago. ° d ONLN døÁÀ˛ (ÁWhy ° d ONLN d À <◊ ˜ (Û Z$does SetPreserveGlyph work this way? ° d ONLN d.◊ <„ N * ___ ° d ONLN d2Ô <˚ *.Glyph preservation is a function of the font. ° d ONLN d`Ô˚˛ )”1It turns out that Times and Helvetica have glyphs ° d ONLN dí˚ < ‡ (# Z#that extend above the ascent line, ° d ONLN dµ˚ ‡˛ )§8thereby enabling SetPreserveGlyph to have an effect on a ° d ONLN dÓ < (/ Z particular glyph. New York, ° d ONLN d
˛ )é<Geneva, Monaco, and Chicago’s characters all fit between the ° d ONLN dG < – (; ZVascent and descent lines, and so do not need to be compressed to fit if preserveGlyph ° d ONLN dù– ˛ (;Ó
is true. A ° d ONLN d® <+ (G ZKfont must have glyphs extending above or below the ascent or descent lines ° d ONLN dÛ +˛ (Gfor ° d ONLN d˜+ <7 Ê (S Z#SetPreserveGlyph to have an effect.
° d ONLN dO <^ Ÿ *'RealFont and TrueType
° d ONLN d1^ <j b * Written: ° d ONLN d:^ àj ¶ )L9/4/91 ° d ONLN dAj <v Å (í ZLast reviewed: ° d ONLN dPj àv ¶ )L8/1/92 ° d ONLN dWÇ <ég (™ Z;What is the story with RealFont and TrueType? I am finding ° d ONLN díÇgé˛ (™Ö that, of the standard System 7 ° d ONLN d±é <öG (∂ Z6fonts, only Symbol and Courier get a TRUE for 7 point. ° d ONLN dËö <¶ N * ___ ◊ X◊
**
TrueType Q&As (Ï1 ) of 3 ˇ ° ¿Ù%%DSIDICT:_cv
currentdict /bu known {bu}if
userdict /_cv known not{userdict /_cv 30 dict put}if
_cv begin
/bdf{bind def}bind def
currentscreen/cs exch def/ca exch def/cf exch def
/setcmykcolor where{/setcmykcolor get /cvcmyk exch def}{/cvcmyk{1 sub 4 1 roll 3{3 index add neg dup 0 lt{pop 0}if 3 1 roll}repeat setrgbcolor pop}bdf }ifelse
/ss{//cf //ca //cs setscreen}bdf
/stg{ss setgray}bdf
/strgb{ss setrgbcolor}bdf
/stcmyk{ss cvcmyk}bdf
/min1{dup 0 eq{pop 1}if}bdf
end
currentdict /bn known {bn}if
† øX ◊# ˇ ˇˇˇˇ # ◊
IR , Times
. +6-Macintosh Technical Notes / 4 /˘
° d ONLN d ) 5 s *$You are absolutely ° d ONLN d ) s 5⁄ )[Icorrect with your observation of RealFont for size 7 and certain TrueType ° d ONLN d ] 5 A R ( ] 6 fonts. The ° d ONLN d h 5 R A⁄ ):Gexplanation is hidden in “The TrueType Font Format Specification” (APDA ° d ONLN d ∞ A M å ( i 6M0825LL/A), page 227: ° d ONLN d Δ Y e - *The ° d ONLN d Y - e⁄ )U“head” FontHeader table contains a field “lowestRecPPEM,” which indicates the “lowest ° d ONLN d e qí ( ç 6Mrecommended pixel number per Em,” or, in other words, the “smallest readable ° d ONLN dm eí q⁄ ( ç∞size in pixels.” ° d ONLN d~ q }π ( ô 6WAs it turns out, the Font Manager in its wisdom uses this information for the value it ° d ONLN d’ qπ }⁄ ( ô◊returns ° d ONLN d› } â• ( • 6Ufrom RealFont. Note that for higher resolution devices, a point size of 7 does *not* ° d ONLN d2 }• â⁄ ( •√
correspond ° d ONLN d= â ï ˜ ( ± 63to 7 pixels; but as the unit “point” is 1/72 inch, ° d ONLN dp â ˜ ï⁄ )fl/and the screen resolution is (approximately) 72 ° d ONLN d† ï ° ˝ ( Ω 64dpi, the result corresponds to reality in this case. ° d ONLN d’ ≠ πS *?The value for lowestRecPPEM can be arbitrarily set by the Font ° d ONLN d ≠S π⁄ ( ’qdesigner. We all know that ° d ONLN d/ π ≈ Ï ( · 6,small point sizes on low-resolution devices ° d ONLN d[ π Ï ≈⁄ )‘0never look “great,” and even less so for outline ° d ONLN då ≈ —à ( Ì 6Sfonts. Courier and Symbol have lowestRecPPEM = 6, while the other outline fonts in ° d ONLN dfl ≈à —⁄ ( ÌÍthe ° d ONLN d„ — ›s ( ˘ 6ESystem have lowestRecPPEM = 9. This doesn’t really mean that Courier ° d ONLN d( —s ›⁄ ( ˘ëand Symbol in size 7 ° d ONLN d= › Èë ( 6M(TrueType) look better than Times or Helvetica under the same conditions. It ° d ONLN dä ›ë È⁄ (Ømeans the font ° d ONLN dô È ı ( 6Jdesigner had higher standards (or was in a different mood) when he choose ° d ONLN d„ È ı⁄ (ùlowestRecPPEM = ° d ONLN dÛ ı " ( 69.
° d ONLN dˆ ( Ó *' Where to find OutlineAccessLib
° d ONLN d( 4 > * Written: ° d ONLN d ( d4 à )L12/9/91 ° d ONLN d&4 @ ] (\ 6Last reviewed: ° d ONLN d54 d@ Ç )L8/1/92 ° d ONLN d<L X¨ (t 6TIs the OutlineAccessLib library, which will provide standardized access routines to ° d ONLN dêL¨X⁄ (t TrueType ° d ONLN dôX d (Ä 65font outline bezier data, available yet? I have been ° d ONLN dŒXd⁄ )Ì-unable to find this in the last few Developer ° d ONLN d¸d p ¬ (å 6 CDs or the MPW 3.2 C release CD. ° d ONLN d p | * * ___ ° d ONLN d!à î Æ * The OutlineAccessLib is now ° d ONLN d=à Æî⁄ )ñ9available (although somewhat disguised and hidden) on the ° d ONLN dwî †≥ (º 6UDeveloper CD Vol. X (and later); it is included in the code accompanying the article ° d ONLN dÃî≥†⁄ (º—“Curves ° d ONLN d‘† ¨ ß (» 6 ahead” in issue #8 of develop.
° d ONLN dÛƒ ”q *'4SetOutlinePreferred affects only calling application
!á ì (Ø 66set or reset this value, it’s supposed to put it back ° d ONLN d
Wáì⁄ )˜(the way it found it when it is done. So, ° d ONLN d
Äì üf (ª 6Jplaying a PICT will not affect the current application’s outline settings. ◊ 4◊˘
*12 ) of 3 (ϵ
TrueType Q&As ˇ¥ ◊# ˇ ˇˇˇˇ # ◊
IR , Times
. +Z-Developer Support Center ( -Ê October 1992 / X /
° d ONLN d < )ê ( E ZHAnd no, OutlinePreferred is not part of a grafport (as mentioned above.)
° d ONLN d I A < Pê *'/QuickDraw doesn’t draw ASCII 32 ($20) character
° d ONLN d y P < \ b * Written: ° d ONLN d Ç P à \ ¨ )L3/18/92 ° d ONLN d ä \ < h Å ( Ñ ZLast reviewed: ° d ONLN d ô \ à h ¶ )L8/1/92 ° d ONLN d † t < Ä— ( ú ZQMy TrueType font has all 256 characters defined with a unique glyph. I have been ° d ONLN d Ò t— IJ ( úÔ unable to ° d ONLN d ˚ Ä < å Ä ( ® Z
draw the $20 ° d ONLN d Ä Ä å˛ )DI(space) character. DrawChar, DrawText, DrawString and DrawJust all ignore ° d ONLN dR å < òê ( ¥ ZIthis character in the font and draw a blank character. How can I draw it? ° d ONLN dú ò < § N * ___ ° d ONLN d† ∞ < º Ó *$Unfortunately, the problem with the ° d ONLN dƒ ∞ Ó º˛ )≤6space character not being drawn is hard-coded into the ° d ONLN d˚ º < »2 ( ‰ Z/text-drawing routine in the core of QuickDraw. ° d ONLN d* º2 »˛ )ˆ$ASCII 32 is always “optimized away,” ° d ONLN dO » < ‘ Ç ( Zregardless of ° d ONLN d] » Ç ‘˛ )FIthe font being used, regardless of the particular circumstances. The only ° d ONLN dß ‘ < ‡Ä ( ¸ ZBworkaround is to put the corresponding character elsewhere in the ° d ONLN dÈ ‘Ä ‡˛ ( ¸ûASCII character encoding ° d ONLN d ‡ < Ï3 ( Z9(or, if this is not possible, to use an additional font). ° d ONLN d< ¯ <– *TYou are lucky that TrueType fonts always render the ASCII code 13 (carriage return) ° d ONLN dê ¯–˛ ( Ó if it has a ° d ONLN dú < [ (, Zglyph ° d ONLN d¢ [˛ ) Uin the font; for bitmap fonts, if the character drawing happens with scaling, or with ° d ONLN d¯ < Ë (8 ZVforeground/background colors different from black/white, even the CHR(13) drawing has ° d ONLN dNË ˛ (8been ° d ONLN dS <( ä (D Zoptimized away. ◊ X◊
(Ï Z
TrueType Q&As (Ï3 ) of 3 ˇN ◊# ˇ ˇˇˇˇ # ◊ † Ç
/ Z Å#
0Ià:µú9 " { ˇˇˇˇˇˇˇˇ # † ƒ ° d
ONLN f ˛ † å ° d 1drw2 … -·_ Ä ˇˇˇˇˇˇ è ° ñ x ° d drw2 : ° d drw2 : $ ° d 4drw2 : ° ö ˇ˙ ó@ † ò , Times
. R… R… +]BNew Technical Notes † ô ° d drw2 : °„ † ó ° d 1drw2 eÙ Ä ˇˇˇˇˇˇ P ° ñ x ° d drw2 : ° d drw2 : $ ° d 4drw2 : ° ö ˇ˚Ä E¿ † ò
( {ïDeveloper Support † ô ° d drw2 : °„ † ó ° d `drw2 - Ô ˇˇˇˇˇˇ K Ô - Z f f Z ° d 1drw2 ¿˙È ˇˇˇˇˇˇ K ° ñ x ° d drw2 : ° d drw2 : $ ° d 4drw2 : 0 ° ö ˇÙ Ä † ò
0 ( UÔ † ô ° d drw2 : °„ † ó ° d 1drw2 ÔÊ˙ ˇˇˇˇˇˇ ° ñ x ° d drw2 : ° d drw2 : $ ° d 4drw2 : ° ö ˇ˝Ä † ò
+& ® † ô ° d drw2 : °„ † ó ° d 1drw2  -¯ y ˇˇˇˇˇˇ ° ñ x ° d drw2 : ° d drw2 : $ ° d 4drw2 : ° ö ˇ˚Ä % † ò
( Z \ Macintosh † ô ° d drw2 : °„ † ó † ç ° d drw2 D † É
IR . ° d ONLN dˇˇ ( ß Z"How to Construct Word-Break Tables
° d ONLN dˇˇ *Text ° d ONLN dˇˇ ( ∑zM.TE.WordBreakTables
° d ONLN dˇˇ ( œ Z Revised by: ° d ONLN dˇˇ ( œ„
March 1988 ° d ONLN dˇˇ ( € Z Written by: ° d ONLN dˇˇ )H
Mark Davis ° d ONLN dˇˇ ( €œ
November 1987 ° d ONLN dˇˇ ( Û ZNThis technical note describes how to construct auxiliary break tables for use ° d ONLN dˇˇ ( ÛÒwith the ,
Courier ° d ONLN dˇˇ ( ZFindWord ° d ONLN dˇˇ )8 routine in the Script Manager. X
° d ONLN dˇˇ (4 ZConstructing break tables
° d ONLN dˇˇ *The ° d ONLN dˇˇ )FindWord ° d ONLN dˇˇ )8 algorithm ° d ONLN dˇˇ )3>finds word boundaries by determining where words should not be ° d ONLN dˇˇ (Y Z*broken. For example, “re-do” is one word: ° d ONLN dˇˇ )’/it should not be broken at the hyphen. In other ° d ONLN dˇˇ (e Z words, a ° d ONLN dˇˇ )-Usequence of the form: (letter, hyphen, letter) should not be broken between the first ° d ONLN dˇˇ (q ZRand second or second and third character. This is called a continuation sequence. ° d ONLN dˇˇ (qŸ
The algorithm ° d ONLN dˇˇ (~ Z used by the ° d ONLN dˇˇ )<FindWord ° d ONLN dˇˇ )8B routine allows for continuation sequences of lengths one, two and ° d ONLN dˇˇ (ä Z[three. Examples of a sequence of length two include (letter, letter), or (number, number). ° d ONLN dˇˇ (äFor a ° d ONLN dˇˇ (ó Z=length of one, there is only one sequence, consisting of the ° d ONLN dˇˇ (óscharacters of type ° d ONLN dˇˇ )Y nonBreaking ° d ONLN dˇˇ )M: ° d ONLN dˇˇ (£ ZLthese characters are never separated from preceding or following characters. ° d ONLN dˇˇ *For ° d ONLN dˇˇ )Zmost scripts, this information about continuation sequences is packed into a table for use ° d ONLN dˇˇ (» Zby the ° d ONLN dˇˇ ) FindWord ° d ONLN dˇˇ )8& algorithm. (For complex scripts like ° d ONLN dˇˇ )∞'Japanese, a different algorithm is used ° d ONLN dˇˇ (‘ ZPfor portions of the script.) The default break tables for a given script can be ° d ONLN dˇˇ (‘Œoverridden by a ° d ONLN dˇˇ (· Zuser-specified ° d ONLN dˇˇ )F
breakTable ° d ONLN dˇˇ )F< parameter, but should only be used for known scripts. That ° d ONLN dˇˇ (·is, ° d ONLN dˇˇ (Ó Zbefore overriding the ° d ONLN dˇˇ )f
breakTable ° d ONLN dˇˇ )F2 parameter, the programmer should first check the ° d ONLN dˇˇ )Ó script of ° d ONLN dˇˇ (˙ Zthe current font. ° d ONLN dˇˇ * A break table consists of two ° d ONLN dˇˇ )åAsections, a 256 byte character type table followed by a character ° d ONLN dˇˇ ( Z
triple table. ◊ X◊
*Œ"How to Construct Word-Break Tables (Ï1 ) of 4 ˇ ° ¿Ù%%DSIDICT:_cv
currentdict /bu known {bu}if
userdict /_cv known not{userdict /_cv 30 dict put}if
_cv begin
/bdf{bind def}bind def
currentscreen/cs exch def/ca exch def/cf exch def
/setcmykcolor where{/setcmykcolor get /cvcmyk exch def}{/cvcmyk{1 sub 4 1 roll 3{3 index add neg dup 0 lt{pop 0}if 3 1 roll}repeat setrgbcolor pop}bdf }ifelse
/ss{//cf //ca //cs setscreen}bdf
/stg{ss setgray}bdf
/strgb{ss setrgbcolor}bdf
/stcmyk{ss cvcmyk}bdf
/min1{dup 0 eq{pop 1}if}bdf
end
currentdict /bn known {bn}if
† ø,, ◊# ˇ ˇˇˇˇ # ◊
IR , Times
. +6-Macintosh Technical Notes / 4 /˘ † Ç † å
< x Úµ
4 › › & 8 ° ñ @ ° ö ˇ˝ † ò
∂= ∫? ° d ONLN dˇˇ +ÃΩbreak † ô † ó
"Dà"Dà 4 › › Á 8 4 › Ê 8 4 › Ô ˘ 8 † ç † å
4 › ñ fi 8 ° ñ @ ° ö ˇ˝ † ò L ° d ONLN dˇˇ ( Í ªbreak † ô † ó
"Dà"Dà 4y Öå è 8 † ç ° ñ ¸ ° ö ˇ˝ † ò ° d ONLN dˇˇ (á înumber † ô † ó ° ñ ¸ ° ö ˇ˝ † ò ° d ONLN dˇˇ )7dot † ô † ó ° ñ ¸ ° ö ˇ˝ † ò ° d ONLN dˇˇ )"number † ô † ó † å
4C ÖV 8 4C ªV È 8
"Dà"Dà 4C ÖV è 8 † ç ° ñ ¸ ° ö ˇ˝ † ò ° d ONLN dˇˇ (P ïhyphen † ô † ó ° ñ ¸ ° ö ˇ˝ † ò ° d ONLN dˇˇ )2letter † ô † ó ° ñ ¸ ° ö ˇ˝
† ò ° d ONLN dˇˇ ).wild † ô † ó † å
4U Öh 8 4U ªh È 8
"Dà"Dà 4U Öh è 8 † ç ° ñ ¸ ° ö ˇ˝ † ò ° d ONLN dˇˇ (b õletter † ô † ó ° ñ ¸ ° ö ˇ˝ † ò ° d ONLN dˇˇ )&hyphen † ô † ó ° ñ ¸ ° ö ˇ˝ † ò ° d ONLN dˇˇ )3letter † ô † ó † å
4g Öz 8 4g ªz È 8
"Dà"Dà 4g Öz è 8 † ç ° ñ ¸ ° ö ˇ˝
† ò ° d ONLN dˇˇ (t úwild † ô † ó ° ñ ¸ ° ö ˇ˝ † ò ° d ONLN dˇˇ )+letter † ô † ó ° ñ ¸ ° ö ˇ˝ † ò ° d ONLN dˇˇ )'hyphen † ô † ó † å
IR ° d ONLN dˇˇ (· 6 The character type table is ° d ONLN dˇˇ )}Aindexed by the character’s ASCII code and contains one type value ° d ONLN dˇˇ (Ì 6for each character. The ° d ONLN dˇˇ )sDcharacter types in the table are limited to values between 1 and 31. ° d ONLN dˇˇ (˙ 6.There are two distinguishing values: the type ,
Courier ° d ONLN dˇˇ )÷ nonBreaking ° d ONLN dˇˇ )M# (= 1) indicates that the character ° d ONLN dˇˇ ( 66is non-breaking; it always continues a word. The type ° d ONLN dˇˇ (@wild ° d ONLN dˇˇ ) (=0) indicates that ° d ONLN dˇˇ )_
the character ° d ONLN dˇˇ ( 6may ° d ONLN dˇˇ )Vor may not break, depending on information in the character triple table, as described ° d ONLN dˇˇ ( 6^below. Otherwise, the choice of numbers to represent character types is completely arbitrary. ° d ONLN dˇˇ *For ° d ONLN dˇˇ )Qexample, the following in MPW Assembler defines character types for use in a word ° d ONLN dˇˇ (7Ù- ° d ONLN dˇˇ (D 6!selection break table, then sets ° d ONLN dˇˇ )í3up a character type table using an assembly macro ( ° d ONLN dˇˇ )˚setByte ° d ONLN dˇˇ )1) ° d ONLN dˇˇ (P 6 to store ° d ONLN dˇˇ )(Scharacter type values in an array. (Note that the character types could have been ° d ONLN dˇˇ (] 6!defined with equate definitions ( ° d ONLN dˇˇ )úEQU ° d ONLN dˇˇ )), ° d ONLN dˇˇ ) 6rather than using the record structure.) Writing the ° d ONLN dˇˇ (i 6(setByte macro is left as an exercise to ° d ONLN dˇˇ )≥:the reader. Note that the break value is the default. This ° d ONLN dˇˇ (u 6Fvalue is not distinguished, but should have no continuation sequences.
° d ONLN dˇˇ *=;============================================================ ° d ONLN dˇˇ *
charWordRec ° d ONLN dˇˇ )lrecord ° d ONLN dˇˇ )H0 ° d ONLN dˇˇ († 6wild ° d ONLN dˇˇ )lds.b ° d ONLN dˇˇ )H1 ° d ONLN dˇˇ )$ ; constant! not in char table. ° d ONLN dˇˇ (™ 6nonbreak ° d ONLN dˇˇ )lds.b ° d ONLN dˇˇ )H1 ° d ONLN dˇˇ )$ ; constant! non-breaking space. ° d ONLN dˇˇ (¥ 6letter ° d ONLN dˇˇ )lds.b ° d ONLN dˇˇ )H1 ° d ONLN dˇˇ )$
; letters. ° d ONLN dˇˇ (æ 6number ° d ONLN dˇˇ )lds.b ° d ONLN dˇˇ )H1 ° d ONLN dˇˇ )$ ; digits. ° d ONLN dˇˇ (» 6break ° d ONLN dˇˇ )lds.b ° d ONLN dˇˇ )H1 ° d ONLN dˇˇ )$; always breaks. ◊ 4◊˘
(Ï 62 ) of 4 (Ïb"How to Construct Word-Break Tables ˇ 6 ◊# ˇ ˇˇˇˇ # ◊
IR , Times
. +Z-Developer Support Center ( -Ï
March 1988 / X / ,
Courier
° d ONLN dˇˇ ( D Z midLetter ° d ONLN dˇˇ )lds.b ° d ONLN dˇˇ )H1 ° d ONLN dˇˇ )$; a'a. ° d ONLN dˇˇ ( N Z midLetNum ° d ONLN dˇˇ )lds.b ° d ONLN dˇˇ )H1 ° d ONLN dˇˇ )$
; a'a 1'1. ° d ONLN dˇˇ ( X ZpreNum ° d ONLN dˇˇ )lds.b ° d ONLN dˇˇ )H1 ° d ONLN dˇˇ )$ ; $, etc. ° d ONLN dˇˇ ( b ZpostNum ° d ONLN dˇˇ )lds.b ° d ONLN dˇˇ )H1 ° d ONLN dˇˇ )$ ; %, etc. ° d ONLN dˇˇ ( l ZmidNum ° d ONLN dˇˇ )lds.b ° d ONLN dˇˇ )H1 ° d ONLN dˇˇ )$; 1,1. ° d ONLN dˇˇ ( v Z preMidNum ° d ONLN dˇˇ )lds.b ° d ONLN dˇˇ )H1 ° d ONLN dˇˇ )$; .1234. ° d ONLN dˇˇ ( Ä Zblank ° d ONLN dˇˇ )lds.b ° d ONLN dˇˇ )H1 ° d ONLN dˇˇ )$; spaces and tabs. ° d ONLN dˇˇ ( ä Zcr ° d ONLN dˇˇ )lds.b ° d ONLN dˇˇ )H1 ° d ONLN dˇˇ )$; add carriage return ° d ONLN dˇˇ ( î Δendr ° d ONLN dˇˇ ( û Z=;============================================================ ° d ONLN dˇˇ +$
with ° d ONLN dˇˇ )H charWordRec ° d ONLN dˇˇ ( ≤ Z wordTable ° d ONLN dˇˇ +$
dcb.b ° d ONLN dˇˇ )H 256,break ° d ONLN dˇˇ ( Δ ~setByte ° d ONLN dˇˇ )HwordTable,nonBreak,$ca ° d ONLN dˇˇ ( – ~setByte ° d ONLN dˇˇ )H-wordTable,letter,('A','Z'),('a','z')('Ä','ü') ° d ONLN dˇˇ ( ⁄ ~setByte ° d ONLN dˇˇ )H.wordTable,letter,'Æ','Ø','æ','ø',('À','œ'),'ÿ' ° d ONLN dˇˇ ( ‰ ~setByte ° d ONLN dˇˇ )HwordTable,midLetter,'-' ° d ONLN dˇˇ ( Ó ~setByte ° d ONLN dˇˇ )HwordTable,midLetNum,$27,'’' ° d ONLN dˇˇ ( ¯ ~setByte ° d ONLN dˇˇ )HwordTable,number,('0','9') ° d ONLN dˇˇ ( ~setByte ° d ONLN dˇˇ )H wordTable,preNum,'$','¢','£','¥' ° d ONLN dˇˇ ( ~setByte ° d ONLN dˇˇ )HwordTable,postNum,'%' ° d ONLN dˇˇ ( ~setByte ° d ONLN dˇˇ )HwordTable,midNum,',' ° d ONLN dˇˇ ( ~setByte ° d ONLN dˇˇ )HwordTable,preMidNum,'.' ° d ONLN dˇˇ (* ~setByte ° d ONLN dˇˇ )HwordTable,blank,$00,' ',$09 ° d ONLN dˇˇ (4 ~setByte ° d ONLN dˇˇ )HwordTable,cr,$0d ° d ONLN dˇˇ (> ~endWith ° d ONLN dˇˇ (H Z=;============================================================
° d ONLN dˇˇ *The character triple ° d ONLN dˇˇ )cGtable is a coded representation of a list of continuation sequences. It ° d ONLN dˇˇ (k Z!consists of a list of packed one ° d ONLN dˇˇ )õ9word triples, preceded by a length word. This length word ° d ONLN dˇˇ (w Z]contains the number of triples minus one. Each triple contains three character types, either ° d ONLN dˇˇ (was ° d ONLN dˇˇ (Ñ Zderived from the ° d ONLN dˇˇ )QcharType ° d ONLN dˇˇ )8 table or the special type ° d ONLN dˇˇ )twild ° d ONLN dˇˇ ) (= zero). The three types ° d ONLN dˇˇ ){ in a triple ° d ONLN dˇˇ (ê Z\are packed into fields five bits apiece, with the most significant bit in the word cleared. ° d ONLN dˇˇ (ê The ° d ONLN dˇˇ (ú Z)first type in the triple is the leftmost. ° d ONLN dˇˇ *OA continuation sequence of length three (xyz) is represented by entering three ° d ONLN dˇˇ (¥’triples into the ° d ONLN dˇˇ (¿ ZZtriple list: xyz, *xy, and yz* (where ‘*’ stands for the type wild, which is always zero). † Ç
œ m
4‰ ù˜ À 8 ° ñ ° ö ˇ˝ † ò <õ <õ ° d ONLN dˇˇ +J1hyphen † ô † ó 4‰ ˜ ¯ 8 ° ñ ° ö ˇ˝ † ò ° d ONLN dˇˇ )3letter † ô † ó † å 4“u 8 4“´ÂŸ 8
"Dà"Dà 4“u 8 † ç ° ñ ° ö ˇ˝ † ò ° d ONLN dˇˇ (flÖhyphen † ô † ó ° ñ ° ö ˇ˝ † ò ° d ONLN dˇˇ )2letter † ô † ó ° ñ ° ö ˇ˝
† ò ° d ONLN dˇˇ ).wild † ô † ó † å
4‰u˜ 8 4‰´˜Ÿ 8
"Dà"Dà 4‰u˜ 8 † ç ° ñ ° ö ˇ˝ † ò ° d ONLN dˇˇ (Òãletter † ô † ó ° ñ ° ö ˇ˝ † ò ° d ONLN dˇˇ )&hyphen † ô † ó ° ñ ° ö ˇ˝ † ò ° d ONLN dˇˇ )3letter † ô † ó † å
4ˆu 8 4ˆ´ Ÿ 8
"Dà"Dà 4ˆu 8 † ç ° ñ ° ö ˇ˝
† ò ° d ONLN dˇˇ (åwild † ô † ó ° ñ ° ö ˇ˝ † ò ° d ONLN dˇˇ )+letter † ô † ó ° ñ ° ö ˇ˝ † ò ° d ONLN dˇˇ )'hyphen † ô † ó
4‰ p˜ û 8 ° ñ ° ö ˇ˝ † ò ° d ONLN dˇˇ (Ò }letter † ô † ó
IR ° d ONLN dˇˇ ( Z+A continuation sequence of length two (xy) ° d ONLN dˇˇ )œ6is represented by entering two triples into this list: ° d ONLN dˇˇ (, ZU*xy, and xy*. A continuation sequence of length one has no entry in the triple list: ° d ONLN dˇˇ (,‡
the character ° d ONLN dˇˇ (9 Ztype is simply ° d ONLN dˇˇ )E nonBreaking ° d ONLN dˇˇ )M. † Ç
H ÑrÚ
4K_^ ˇˇˇˇˇˇˇˇ 8 4Kï^√ 8 ° ñ ° ö ˇ˝ † ò *n *n ° d ONLN dˇˇ +µ letter † ô † ó ° ñ ° ö ˇ˝
† ò ° d ONLN dˇˇ )/wild † ô † ó
"Dà"Dà 4K_^i 8 ° ñ ° ö ˇ˝ † ò ° d ONLN dˇˇ (Xuletter † ô † ó † å
4]_p 8 4]ïp√ 8
"Dà"Dà 4]_pi 8 † ç ° ñ ° ö ˇ˝
† ò ° d ONLN dˇˇ +wild † ô † ó ° ñ ° ö ˇ˝ † ò ° d ONLN dˇˇ )+letter † ô † ó ° ñ ° ö ˇ˝ † ò ° d ONLN dˇˇ )-letter † ô † ó
4T ág µ 8 ° ñ ° ö ˇ˝ † ò ° d ONLN dˇˇ (a îletter † ô † ó 4T ¥g ‚ 8 ° ñ ° ö ˇ˝ † ò ° d ONLN dˇˇ )-letter † ô † ó
IR ° d ONLN dˇˇ (à ZNote that the type ° d ONLN dˇˇ )Vwild ° d ONLN dˇˇ ) < cannot appear as the middle element of a triple. The words ° d ONLN dˇˇ (àÂ
in the triple ° d ONLN dˇˇ (î ZKtable must be sorted in ascending numerical order for future compatibility. ° d ONLN dˇˇ *PThe following is an example of how a character triple table could be coded. The ° d ONLN dˇˇ (≠ÚdefSeq ° d ONLN dˇˇ (π Zmacro takes a continuation ° d ONLN dˇˇ )ÄEsequence as a parameter, and enters a set of triples into an internal ° d ONLN dˇˇ (Δ Z array. The ° d ONLN dˇˇ )6dumpSeq ° d ONLN dˇˇ )1C macro sorts the triples, and stores them in the proper order with ° d ONLN dˇˇ (Δ dc.w ˇˇˇˇˇˇˇˇ ◊ X◊
(Ï Z"How to Construct Word-Break Tables (Ï3 ) of 4 ˇ
R ◊# ˇ ˇˇˇˇ # ◊
IR , Times
. +6-Macintosh Technical Notes / 4 /˘
° d ONLN dˇˇ *commands. Once again, ° d ONLN dˇˇ )xwriting the macros ,
Courier ° d ONLN dˇˇ )^defSeq ° d ONLN dˇˇ )* and ° d ONLN dˇˇ )dumpSeq ° d ONLN dˇˇ )1 is left as an exercise for ° d ONLN dˇˇ ( R 6 the reader.
° d ONLN dˇˇ *=;============================================================ ° d ONLN dˇˇ +$
with ° d ONLN dˇˇ )H charWordRec ° d ONLN dˇˇ ( } ZdefSeq ° d ONLN dˇˇ )H
letter,letter ° d ONLN dˇˇ ( á ZdefSeq ° d ONLN dˇˇ )Hletter,preMidNum,letter ° d ONLN dˇˇ ( ë ZdefSeq ° d ONLN dˇˇ )Hletter,midLetter,letter ° d ONLN dˇˇ ( õ ZdefSeq ° d ONLN dˇˇ )Hletter,midLetNum,letter ° d ONLN dˇˇ ( Ø ZdefSeq ° d ONLN dˇˇ )H
number,number ° d ONLN dˇˇ ( π ZdefSeq ° d ONLN dˇˇ )H
number,letter ° d ONLN dˇˇ ( √ ZdefSeq ° d ONLN dˇˇ )Hnumber,midNum,number ° d ONLN dˇˇ ( Õ ZdefSeq ° d ONLN dˇˇ )Hnumber,midLetNum,number ° d ONLN dˇˇ ( ◊ ZdefSeq ° d ONLN dˇˇ )Hnumber,preMidNum,number ° d ONLN dˇˇ ( · ZdefSeq ° d ONLN dˇˇ )Hnumber,postNum ° d ONLN dˇˇ ( Î ZdefSeq ° d ONLN dˇˇ )H
preNum,number ° d ONLN dˇˇ ( ı ZdefSeq ° d ONLN dˇˇ )HpreMidNum,number ° d ONLN dˇˇ ( ZdefSeq ° d ONLN dˇˇ )H blank,blank ° d ONLN dˇˇ ( ZdefSeq ° d ONLN dˇˇ )Hblank,cr ° d ONLN dˇˇ ( ZendWith ° d ONLN dˇˇ (1 6=;============================================================ ° d ONLN dˇˇ +$
dc.w ° d ONLN dˇˇ )$((wordEnd-wordBegin)/2)-1 ° d ONLN dˇˇ )ê; length word. ° d ONLN dˇˇ (E 6 wordBegin ° d ONLN dˇˇ +$
° d ONLN dˇˇ * A series ° d ONLN dˇˇ )+Qof blanks should generally select as a single word. Make certain, however, that a ° d ONLN dˇˇ (Ü 6)carriage return does not continue a word ° d ONLN dˇˇ )¡7to the right (note how it has a separate character type ° d ONLN dˇˇ (í 6Ofrom blank for this reason), otherwise word selection and wrapping do not work ° d ONLN dˇˇ (í–properly ° d ONLN dˇˇ (û 6across paragraphs.
° d ONLN dˇˇ *'
Extensions
° d ONLN dˇˇ *The values 16-31 in the ° d ONLN dˇˇ )rJcharacter type table entry for null ($00) (the first byte in the character ° d ONLN dˇˇ (È 6Jtype table) are reserved by Apple for future expansion. The use of one of ° d ONLN dˇˇ (Èëthese values indicates ° d ONLN dˇˇ (ı 6=the presence of a supplementary table after the triple table. ° d ONLN dˇˇ *0Further Reference: ( 4(˘ ° d ONLN dˇˇ +
• ° d ONLN dˇˇ )The Script Manager ◊ 4◊˘
(Ï 64 ) of 4 (Ïb"How to Construct Word-Break Tables ˇ
